Forum.ArchosFans.com

Unofficial Archos Support Forum
It is currently Sun Sep 22, 2019 3:21 am

All times are UTC+01:00




Post new topic  Reply to topic  [ 21 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Thu Feb 26, 2009 7:32 pm 
Offline
Archos Guru
Archos Guru

Joined: Mon Oct 15, 2007 3:51 pm
Posts: 1268
Location: US
Android on the G1 has a great interface, but uses a very constrained Java SDK and the overhead that and Gstreams makes for a sluggish Java layer for games and higher end apps. The SDK is very weak compared to Apple's for the iPhone- this is a fact that devs are ticked off about in regards to Android.

Archos 5, well, great video player but easily the suckiest sound of any media device I have ever owned (and I own a LOT)

Zen Stone, Zen 32gb, Zune 120gb and Gmini 402, G1 and Sony Walkman phone just to name the main ones.

Heck, the G1 phone BLOWS AWAY the sound quality of the Archos 5 and it uses a USB adaptor for 3.5mm

In short, I would hardly call the constrained OS of Android and the constrained sound quality of the Archos products "the best of both worlds". Not at all.


Top
   
PostPosted: Thu Feb 26, 2009 10:44 pm 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
You obviously have no real knowledge of the Android SDK and it's possibillities versus the icrap.

Very advanced OpenGL 3D games even N64, Dreamcast emulation can be achieved using Android and a hardware like the Archo 5 (with OpenGL acceleration option on the Texas Instruments chip) as long as the hardware used provides APIs to use those hardware acceleration features. Same thing with HD video decode/encode, electronic compass, bluetooth zigbee features, higher bandwidth bluetooth, all those things are taken from hardware and available in customized Android platforms.

Just cause the HTC G1 is pretty bad hardware in terms of multimedia codecs, graphics acceleration, screen size and resolution, that does not say anything about the possibillities of the Linux based open-source OS. It's Linux based open-source in the way Archos can take it and do anything they want with it and that they have the industry's best tools from the industry's best company Google to do what they want with it based on the hardware that they can provide.


Top
   
PostPosted: Fri Feb 27, 2009 12:32 am 
Offline
Archos Guru
Archos Guru

Joined: Mon Oct 15, 2007 3:51 pm
Posts: 1268
Location: US
Charbox,

The SDK is the problem. You are forced to program in the sandbox known as the Java layer. You can not get the root access required to run any emulator smoothly- even a Gameboy emu at full speed and with sound. Email the Smartgear author (great emu) or the Coreplayer dev team if you want to learn more. The OS is locked down and there are LESS resources in regards to accessing hardware when compared to the already constrained iPhone OS.

The hardware is irrelevant- it is the lack of root access. This creates clock cycle resources that will make MAME and any console emu impossible on the Android- unless it is a hacked version of the OS and not requiring the Java layer to operate. I respectfully think you may be the one with no real knowledge in regards to Android. The drivers MUST be baked into the OS (Android) or they will NOT work. Please trust me on this. Actually, no need- please speak to any commercial dev and they will tell you the same exact thing.

Do you think Archos is going to allow an unlocked OS with root access? Android certainly will not, since it compromises the main framework of the OS- you MUST use the Java layer in the SDK.

The G1 and iPhone both use a very capable 7201a chipset. It is more powerful than a PSP- IF you had root hardware access. iPhone SDK has some access, but Android does not.

Good luck with them 15 fps Gameboy emulators while you are jamming to the Archos weak sound ;)


Top
   
PostPosted: Fri Feb 27, 2009 12:59 am 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
Again rushmore, just plain wrong, no no and no.

The Android Java layer is for the basic functionalities of apps, that absolutely does not limit the amounts of hardware APIs that can be added to Android to do all sorts of VERY advanced things. In fact, Android has absolutely no limits in terms of what it can do, it all comes down to how many hardware features the manufacturer decides to add to it.

HTC G1 has pretty crappy hardware, no 3D graphics accelerator, no powerful video playback and recording processor, all those things basically leave obviously no way to program emulators or advanced multimedia video playback applications.

rushmore wrote:
This creates clock cycle resources that will make MAME and any console emu impossible on the Android- unless it is a hacked version of the OS and not requiring the Java layer to operate. I respectfully think you may be the one with no real knowledge in regards to Android. The drivers MUST be baked into the OS (Android) or they will NOT work.


That is exactly what Android is designed for, being hacked and baked by the manufacturers which can add ANY hardware modules that they want and manufacturers can add or port any drivers that they want to Android for any of those advancced and dedicated hardware functions. You can absolutely add a DSP based OpenGL ES 2.0 based graphics acceleration to Android and then use that in any Android application that is written to take advantage of that hardware based graphics acceleration core. Which means an Archos with Android, if they want to design it with advanced video-games capabillities, it could definitely emulate such consoles as N64, Dreamcast, PSX, NES, SNES and MAME video games and that is just using the current generation of Texas Instruments graphics acceleration technology. Advanced Linux compatible Open GL games such as Quake 3 and Unreal Tournament are also totally possible.


Top
   
PostPosted: Fri Feb 27, 2009 1:37 am 
Offline
Archos Guru
Archos Guru

Joined: Mon Oct 15, 2007 3:51 pm
Posts: 1268
Location: US
Charbox, you are a cool dude, but:

1) 7201a has 3d acceleration- there are several demos that can be installed to prove that- the specs note it too. It plays Quake smooth as butter- with sound. I have seen it had the demos on my own G1. I am a game and tech NUT- MAME and every console emu (Favorite is NullDC- great Dreamcast emu). Plus a an i7 desktop, six gigs ram etc.

2) Again you are assuming Archos will allow the OS to be unlocked and a dev community will join and make a bunch of apps for Archos devices- if unlocked. Does Archos allow the current OS to be unlocked on the Archos 5? Archos will not allow Android to be unlocked- that would be a tech support nightmare. Most consumers would not see the benefit of an unlocked Android OS.

3) Android is not a one size fits all- each rom OS created and compiled must be created for each device (drivers, etc).

4) Android is a resource hog- if you do not adhere to the Java layer in the SDK.

5) The only other alternative is to work with Dianne and the rest of the OS dev team and have drivers created specifically for each device and allow root hardware access= specifically for each rom created (depending on if hardware is different, of course).


Top
   
PostPosted: Fri Feb 27, 2009 1:46 am 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
rushmore wrote:
2) Again you are assuming Archos will allow the OS to be unlocked and a dev community will join and make a bunch of apps for Archos devices- if unlocked. Does Archos allow the current OS to be unlocked on the Archos 5? Archos will not allow Android to be unlocked- that would be a tech support nightmare. Most consumers would not see the benefit of an unlocked Android OS.


I am not assuming that at all. Archos can provide a Java-only environment for all third party applications simply giving developpers a set of API call strings that developpers can use in their applications if they want to use any of the Archos specific hardware features in Android, which may be the higher resolution screen, video recording, HDMI video output basically up to 1280x720 desktop screen interfaces are supported on an external HD screen, advanced OpenGL graphics acceleration tasks can be sent using a 3D graphics API. Basically the 3D graphics engine is pretty dum, it can process a large amount of data in a pretty simplistic way and not in a multi-purpose way so sure you would have to write emulators to use such graphics acceleration, but that would be Archos providing some sort of 3D engines layers on top of their POWERVR SGX graphics core, and supports OpenGL ES 2.0 and OpenVG.

The legallity of games emulation still being unsure, I'd say you cannot expect advanced games emulation to be supported unless a change happens soon in terms of Nintendo licencing all Nintendo games for compatible Android platforms. Perhaps Nintendo will even require to approve the hardware design before granting third party licencing to the games, but perhaps not. It just depends which kind of pressure and common sense Nintendo can have in the next few months as more and more powerful hardware is available which all could emulate all generations of Nintendo games pretty well. Nintendo could see the opportunity for a few billions to be made in licencing their old games, or they could keep ignoring the opportunity and then still nothing will happen. Unless copyright laws are changed, don't expect advanced games emulation to be supported by anyone else than hackers doing multipurpose emulator hacking on niche products.


Top
   
PostPosted: Fri Feb 27, 2009 9:41 am 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
Charbax wrote:
rushmore wrote:
2) Again you are assuming Archos will allow the OS to be unlocked and a dev community will join and make a bunch of apps for Archos devices- if unlocked. Does Archos allow the current OS to be unlocked on the Archos 5? Archos will not allow Android to be unlocked- that would be a tech support nightmare. Most consumers would not see the benefit of an unlocked Android OS.


I am not assuming that at all. Archos can provide a Java-only environment for all third party applications simply giving developpers a set of API call strings that developpers can use in their applications if they want to use any of the Archos specific hardware features in Android, which may be the higher resolution screen, video recording, HDMI video output basically up to 1280x720 desktop screen interfaces are supported on an external HD screen, advanced OpenGL graphics acceleration tasks can be sent using a 3D graphics API.


This is exactly the kind of thing I've been bitching about all along. The Java VM might be (a) too slow and (b) to sandboxed to create useful apps. Archos (or any other Vendor) can add to the Java API with vendor specific features as you correctly say. Nokia does this with the Java implementation in its phone handsets.

The problem with this is that:

(a) Vendors don't like to do this if they don't have to, because each new hook into the lower levels of the system provides a new hacking opportunity -- and Archos is more paranoid than most in this respect; and
(b) Developers don't use the features anyway, because they tie their code to a particularly platform.

So far as I know, the only people who use the Nokia-specific extensions on Nokia phones are
1. Nokia, and
2. Inexperienced developers who haven't read the platform Spec, and don't know that they are using vendor-specific features.

Show me a really useful Java app that runs on a phone handset, and that comes from some place other than the handset vendor, and I might be prepared to change my tune on this.

Of course, nobody would be happier than me if I turned out to be wrong.


Top
   
PostPosted: Fri Feb 27, 2009 9:51 am 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
Archos is the first to announce an Android Internet Media Trablet with a 800x480 4.8" screen, hard drive storage, OMAP3440 (which I think has OpenGL 3D and 720p video playback) and obviously all the features from Gen6 going over such as video recording, Docks with USB host, DVB-SH and DVB-T very probably available by the release either Docks or built-in. You can be sure all these involve API hooks into the Android Java platform.

Sure Archos may probably provide their own applications in Android for such things as video playback with all the codecs, video recording, Docks functionality and other stuff, perhaps even the browser is going to be Opera again as well cause it probably works better on a 800x480 screen with AJAX and Flash video than the current version of the Google developped Webkit based browser. Though that could change for the browser or people could have more choices such as an Android version of Google Chrome would be great.

Anyways, if it isn't too hard, of course Archos will provide API hooks to use their specific hardware features in Android applications. In any ways the Android applications will perhaps need to be ported anyways to support the high resolution screen, the extra storage for example. Video and audio playback should probably use the standard Android call strings for it, though Archos video playback is much more advanced than HTC G1 video playback, so in any ways, there can be much more powerful Android applications that could use video decoding on the Archos than there would be for video applications for other Android products.


Top
   
PostPosted: Fri Feb 27, 2009 11:27 am 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
Charbax wrote:
Anyways, if it isn't too hard, of course Archos will provide API hooks to use their specific hardware features in Android applications. In any ways the Android applications will perhaps need to be ported anyways to support the high resolution screen, the extra storage for example.


Well, I don't share your confidence, but we'll see, won't we?

For my part, I am more concerned about how Archos will handle things like the filesystem and networking APIs. It's going to be very difficult to make real, useful apps with crippled file access, and I fear that Archos, in its paranoia, will cripple file access.

I wonder if the chap who owns the G1 is in a position to comment on how that device handles file access? Does it support apps that read and right files? And, if so, are they limited to specific types or locations?


Top
   
PostPosted: Fri Feb 27, 2009 11:50 am 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
Google is most likely working with Texas Instruments and other hardware providers to actually make sure those drivers for different hardware components work great with Android and I am sure hard drive storage support is going to work. My bet is that already there must be Google Android engineers who must be very eager to work with Archos to help making sure all the components are integrated correctly and work in Android the best way possible.

The only problem might be that Archos may not be interested if the customized drivers and other customizations and all that would be released by Google as open-source or to competing hardware manufacturers and if Archos requires exclusivities, then Google might not dedicate that kind of high level support to Archos for such exclusive hardware integration deals. Like Texas Instruments for example often works with Archos engineers to make new Texas Instruments processors work correctly in Archos devices and in exchange gives Archos exclusivities before using those research and development results with other companies.

The best would probably be if Google would send a bunch of engineers to work with Archos for a few months to make sure all the drivers for 720p video, 800x480 resolution large touchscreen, huge hard drive storage, with HSDPA, Bluetooth and WiFi and even perhaps with openGL emulation opportunities once game publishers agree to make a deal with Google to release games on the Android marketplace. Google could perhaps help to make sure that all those very advanced hardware functions are not only used in proprietary software within Android, but that all of it also works smoothly for any third party Android applications that could be made compatible with these kinds of awesome specs.

By sending 3 Google engineers to work with Archos over a period of a few months, this could provide Google with everything they need to provide a great Android for IMTs, though that would probably require for Google to actually buy Archos since the Archos knowledge in this space would then be used to accelerate the advanced usage of Android in these types of higher end devices.


Top
   
PostPosted: Fri Feb 27, 2009 12:13 pm 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
I'm not saying that these limitations could not be fixed. No doubt they could, with good will on all sides.

The question is: given Archos' record so far, will they be fixed?

However much we may admire Archos products (those of us who still do :) ), we've got to admit that Archos doesn't have a good record when it comes to encouraging third-party developers. Remember the PMA400? Even then, when it was part of Archos' stated goal to encourage 3rd-party development, but they did absolutely nothing to bring it about. They even produced vendor-specific APIs for the cool hardware features -- image scaler, video decoder, etc -- but they failed to document them in a way that a typical developer would be able to understand. As a result, nobody except me (so far as I know) ever wrote a line of original code for the PMA400.

Making an Android device that is both useable for developers, and doesn't compromise Archos' security policies, and is well-document enough to code for -- these are difficult jobs. Archos really is going to have to try harder than it has in the past to do these things properly.


Top
   
PostPosted: Fri Feb 27, 2009 12:27 pm 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
Documentation and all that now is the job of Google, the best company in the world.

Archos just needs to take care of customizing the basic Android OS to make it work with Archos specific integration of the Texas Instruments OMAP3440 processor.

Already Android is ready for OMAP3440, so now it's just a matter of making sure every single hardware feature will work perfectly by releasing the first commercial product actually using the working Android for OMAP3440 processor.

The hardware API hooks using OMAP3440 features in Android most probably are things even Texas Instruments can work directly with Google to make sure will be working for every part and every speciality of the OMAP3440 platform using third party Android applications.

The higher resolution large touchscreen, the large hard drive storage, those things could be pretty special and need extra much adaptation work done. I think it is pretty obvious that all of these hardware aspects will be available for third party Android applications to use.

These combinations of features would not be possible with anyone else than Google taking care of that optimal integration of the Linux embedded operating systems platform and taking care of all the documentation, optimization and standardisations work that goes with that.


Top
   
PostPosted: Fri Feb 27, 2009 1:39 pm 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
Charbax wrote:
Documentation and all that now is the job of Google, the best company in the world.


I doubt that Google will want to document any Archos-specific additions to the Java API, even if Archos actually offers any. I'm pretty sure they'll see that as Archos' job.

The Android Java API is already reasonably well documented; but if Archos modifies it (for security purposes, for example) then, again, Archos will have to document it and make potential developers aware.

None of this is rocket science, but it all takes time and costs money.

Quote:
Archos just needs to take care of customizing the basic Android OS to make it work with Archos specific integration of the Texas Instruments OMAP3440 processor.


Having done some work in this area, I'd be a bit careful about the word `just' there. It's not a trivial job. But it is a do-able job, given time and money.

Quote:
The hardware API hooks using OMAP3440 features in Android most probably are things even Texas Instruments can work directly with Google to make sure will be working for every part and every speciality of the OMAP3440 platform using third party Android applications.


Maybe -- let's hope so. But, again, previous experience has not been very positive in this respect. TI has so far not published any way to develop for those parts of the OMAP platform other than the ARM code (e.g., video acclerator) except using their proprietary tools. It's going to cost Google money to get to that stuff, I think. They won't want to do it just for Archos -- whether this works will depend, I guess, on widely the same platform is used by a range of vendors.

Quote:
The higher resolution large touchscreen, the large hard drive storage, those things could be pretty special and need extra much adaptation work done. I think it is pretty obvious that all of these hardware aspects will be available for third party Android applications to use.


It's not obvious to me. I hope you're right, but it's not obvious.


Top
   
PostPosted: Fri Feb 27, 2009 2:40 pm 
Offline
Archos Guru
Archos Guru

Joined: Mon Oct 15, 2007 3:51 pm
Posts: 1268
Location: US
Android is very strict on what is accessed and where files are written to. You must have absolute adherence to the Java layer and the SDK parameters for coding. Creating something as simple as a video or audio codec creates so much overhead due to Java and the security that it is not practical. Insight into this can be found at the Coreplayer forums. Coreplayer was going to port their excellent multi media app to Android but are currently on hold due to the resourse overhead issues with Android.

Larry Banks who programmed the excellent Smartgear app (emulates game systems) has decided not to port, because of the same reason- games are too slow. Again, the security is the key issue and if the resources are not already allocated in the OS, there is not point in trying.

The only way Charbox's scenario plays out is if Archos allows Android to be open (not happening) or Android dev team creates special access just for Android (not happening- due to security of the OS).

To give you some perspective- you can not even create an audio EQ in Android. Raw audio stream are locked out of access.

I think the Archos community will run into the same letdown that the G1 community already has:

1) Android is not really an open OS, because the devices they are on have the OS locked.
2) Android needs to be compiled with drivers for every device (not one size fits all)
3) Emulators that play at smooth FPS and with audio are not practical- due to the VERY strict Java layer
4) The Java platform used is very weak compared to iPhone's in regards to hardware resources available
5) Android does not allow app installation on anything but DIRECT system memory.
6) Android dev team's number one priority is SECURITY. Go to Google Android forums for insight into this.

Android and locked devices are a contradiction in premise, but that is the irony, since all the devices are locked due to tech support costs.


Top
   
PostPosted: Fri Feb 27, 2009 3:09 pm 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
rushmore wrote:
To give you some perspective- you can not even create an audio EQ in Android. Raw audio stream are locked out of access.


To be fair, the Android Java API was never developed to support this kind of thing. Because the Java API must be platform-agnostic (otherwise there is no portability of apps between devices), low-level operations involving hardware are always going to be out of the question. Goodness knows, it's difficult to do anything like this using Java on a desktop PC, let alone a handheld device.

The Java API abstracts low-level services in a platform-neutral way (just as desktop/server Java does). The price for portability across all hardware is that you only get lowest-common-demoninator stuff -- you can read and write files, but you can't read and write disk partitions, because some platforms don't have a concept of `disk'. You can write to a virtual screen framebuffer, but you can't write to an image processing pipeline, because not all platforms have an image processing pipeline. And so on.

The Java API should provide a straightforward, platform-agnostic way of authoring straightforward productivity apps -- calendars, file browsers, messaging, word processing -- and simple games. The virtualisation and security layer are always going to make it impractical for heavyweight apps, or complex games -- just as is the case with Java on the desktop.

Using a Java VM (or some other language that lends itself to cross-platform operation) is a great idea on Android, because it will make it possible (if your careful) to write apps that work on a whole range of different devices. You won't need to recompile or anything like that -- the Java VM offers cross-platform compatibility at the compiler output level. But the down-side of that is you're restricted in what you can do.

It would be a shame if vendors (not just Archos) crippled the Java implementation, in the interests of security, so that it could not even do the things it is good for.


Top
   
PostPosted: Fri Feb 27, 2009 5:14 pm 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
kb wrote:
Charbax wrote:
The hardware API hooks using OMAP3440 features in Android most probably are things even Texas Instruments can work directly with Google to make sure will be working for every part and every speciality of the OMAP3440 platform using third party Android applications.


Maybe -- let's hope so. But, again, previous experience has not been very positive in this respect. TI has so far not published any way to develop for those parts of the OMAP platform other than the ARM code (e.g., video acclerator) except using their proprietary tools. It's going to cost Google money to get to that stuff, I think. They won't want to do it just for Archos -- whether this works will depend, I guess, on widely the same platform is used by a range of vendors.


Texas Instruments already has Android working for OMAP3440 series, according to a quick Google search just see here:

http://focus.ti.com/pr/docs/preldetail. ... Id=sc09022

Quote:
TI's Mobile World Congress demonstrations on the Zoom OMAP34x-II MDP include:

- High-quality multimedia at WVGA resolution to support easy viewing of the latest Web and video content with extended playback time
- Enhanced photo capture and viewer, supporting images up to 8 megapixel
- High-performance Web browsing with super-fast Web page renderings and quick access utilizing Wi-Fi connectivity (802.11 b/g/n)
- Platform support for integrated 3G modems, providing the flexibility for customers to select modem of choice

Continued investments on Android Platform

TI is working with the Open Handset Alliance, to further extend the capabilities of Android, the OMAP processor and TI connectivity solutions to deliver:

- High-definition multimedia with support for video/audio record and playback
- 2D/3D hardware-accelerated graphics support for optimal power and performance
- Support for additional connectivity technologies including 802.11n, Bluetooth®, FM receive, FM transmit and GPS
- Commercial digital still camera quality image processing made possible with advanced imaging algorithms


Those are exactly the type of Android integrations and customizations on the OMAP3440 that Archos is going to use.

http://www.ti.com/androidproject

TI ZOOM OMAP 34x II MDP Android demo on WVGA touch display:

http://www.youtube.com/watch?v=-kgCaASk1yc


Top
   
PostPosted: Fri Feb 27, 2009 5:47 pm 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
Charbax wrote:
Texas Instruments already has Android working for OMAP3440 series, according to a quick Google search just see here:

http://focus.ti.com/pr/docs/preldetail. ... Id=sc09022


Fair enough. But that's only of limited interest, I think, because Archos can already produce decent media players as media players. There's an argument to be made, I suppose, that an increased involvement of TI in this area will take some of the development burden off Archos, at least so far as the DSP side of things is concerned. But since Archos buys this stuff in already (so far as I know) I don't know how helpful that is.

What make Android interesting to me is the potential to install applications from a range of different suppliers (including myself :) ), which may have been developed for different hardware. To do that doesn't require the intervention of TI, or even of Google. It requires that Archos develop a culture of openness with respect to what software can be installed, and what access it will have to the underlying system. As I said, our previous experience in that area has not be all that marvellous.

It's possible, I suppose, that Google or its affiliates may create applications that OEMs like Archos may choose to supply with their units (perhaps at extra cost), even if they don't allow arbitrary 3rd-party apps to be installed. That would be better than limiting users to apps supplied by Archos alone, which is the current policy. But it's a far cry from the open platform that everybody is asking for.

But we'll have to see, I guess.


Top
   
PostPosted: Fri Jul 03, 2009 11:37 am 
Offline
Archos Guru
Archos Guru

Joined: Sun Oct 12, 2008 5:59 pm
Posts: 523
rushmore wrote:
Android on the G1 has a great interface, but uses a very constrained Java SDK and the overhead that and Gstreams makes for a sluggish Java layer for games and higher end apps. The SDK is very weak compared to Apple's for the iPhone- this is a fact that devs are ticked off about in regards to Android.

Archos 5, well, great video player but easily the suckiest sound of any media device I have ever owned (and I own a LOT)

Zen Stone, Zen 32gb, Zune 120gb and Gmini 402, G1 and Sony Walkman phone just to name the main ones.

Heck, the G1 phone BLOWS AWAY the sound quality of the Archos 5 and it uses a USB adaptor for 3.5mm

In short, I would hardly call the constrained OS of Android and the constrained sound quality of the Archos products "the best of both worlds". Not at all.


The sound quality of the Archos 5 is definitely not as bad as you make it. I have owned plenty of players and used to use Cowon and Creative Labs players exclusively because they offer what is widely considered the best sound quality on the market. The Archos 5 has an average amount of distortion and, with some 'phones, can have a slightly shrill highend, but in no way are they that bad. They actually sound pretty good and can be tolerated better than many mp3 players, atleast to me. If you want to actually hear your music then turn the EQ to flat and enjoy real music. This is coming from someone who takes audio very seriously, I use a pair of Ultimate Ears Super.fi 5 Pros with my Archos and own a pair of Grados Reference 1 headphones for my PC.

All things considered also remember that sound is totally subjective and there can be do blanket statements such as "the best sound quality" or the "worst sound quality".


Top
   
PostPosted: Fri Jul 03, 2009 1:26 pm 
Offline
Site Admin
Site Admin

Joined: Sun Nov 27, 2005 2:40 am
Posts: 7052
Location: Copenhagen
There is also now an Android Native Development Kit: http://developer.android.com/sdk/ndk/1.5_r1/index.html

Quote:
The Android NDK is a companion tool to the Android SDK that lets Android application developers build portions of their apps in native code.


You can be sure that Archos is doing a lot of things in Native Code in Android only to provide an even more powerful set of APIs for Android applications developers or just Archos themselves to be able to provide the best Android applications of the industry.


Top
   
PostPosted: Fri Jul 03, 2009 8:57 pm 
Offline
Archos Guru
Archos Guru

Joined: Tue Jan 08, 2008 11:19 am
Posts: 1745
The C API is pretty limited right now. But it's conceptually interesting, in that it _might_ provide for access to some of the Linux devices in /dev, for example. So some sort of direct framebuffer access might possible, which is potentially good news. But I note that there is no implementation of the ioctl() function, which will limit what can be done with this approach (if the implementation even allows it).

Still, if Android is prepared to allow native code to run at all -- and it isn't heavily virtualized to keep it sandboxed -- then this is potentially good news for developers.

My concern is that vendors won't necessarily want to support the native API, if they are worried that it will provide a hacker's back-door.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 21 posts ]  Go to page 1 2 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited