[Legend General] mikereidis:
Great, thanks for your report ! I've been wondering if interest has dissipated, perhaps in part due to the existence of the CM FM app. But the recent XDA website downtime may be an issue too.

Please note that many of the bugs/limitations in my app will be identical in the CM app, so many bug reports will be useful for either app.

>The layout is decent, but the UI and colors definitely need tweaking.

Yes. Ideally the app would be skinnable and colors user selectable. If you or anyone wants to elaborate, I'm listening.

But I could just document the contents of the APK resource directories, and anyone with some knowledge of how that

works could change colors, button icons, etc. without needing to rebuild the app.

>I'm also not sure what it has over the built in CM radio app at this point? (Besides potential for awesomeness =])

See my "CM App/Open Source" section at the end. Basically I might get involved with the CM app, or fork it. So perhaps

my app and the CM app could become one, even more awesome app.

As of now, my app (but not the underlying API) is developed with Googles' "App Inventor". That results in some serious

limitations, so I'm now working to get a normal Java app running (possibly the CM app). One potential plus of using

"App Inventor" is that the app can be opened to a larger audience for customization, adding features or creating whole

new apps. App Inventor is relatively easy to get started with, and a half decent introduction to Android APIs.

I haven't seen the CM app running yet, but I've peaked at the code and the latest patches for TI/Legend support. The CM app

seems to write registers blindly, and can't read them. (There's actually some strange stuff done with return codes that may

work a bit with Broadcom chips, but I don't think it can with TI chips.)

My API can read the registers, to get things like RSSI (signal strength). My API can do seeks. Can the CM app ? My app and API

are able to startup without adversely affecting any currently running radio selections. More on that in next:

The default method of reading/writing FM chip registers for my app and the CM app is running the hcitool binary in a temporary

shell process. That's a very unideal method which can be slow and use a lot more resources. My app has the daemon which can

speak directly to the HCI/bluez APIs. This is very much preferred, especially for functions such as reading RSSI regularly.

My daemon can get many things done in 100-200 milliseconds, while the hcitool method can take roughly twice that. With a Java

app it should be possible to do this in almost no time, say a few milliseconds.

>As far as bugs go... I'm currently listening to the radio........ and your app isnt on. I'm kinda confused.

That's not a bug, it's a feature. :) If, perchance, my app crashed, it can be restarted without affecting the currently

running tuning and audio stream. Also, my app can be stopped, perhaps to save memory or reduce CPU usage and thus

battery consumption. Currently, there's a bit of a click when restarting though.

This "feature" does have some minor negatives, such as allowing sound/music from another app to get intermingled with the

FM radio sound, instead of having one take priority. This feature is a result of using an analog audio connection more or

less directly from the FM chip to the speaker or headset. We can't change the hardware, but it's possible a digital connection

can be used for cases where the "feature" is a problem, as well as for using BT headsets or possibly recording the audio.

>After I started it up (the Daemon option was making things weird - I know you said you recommended not touchy the floppy, but I saw the Daemon option in it...)

Yes, feel free to mess around a bit. I tried to make it relatively safe, but some things can cause issues. Clearing the app data should

put the config DB back to default if any problems arise.

If you can elaborate on the weirdnesses, that would be great. I can't think of any questions to ask right now to help trouble-shoot. As I'm looking to move to a real Java app,

it may not be worthwhile to troubleshoot the current app much.

>and then left the app (by pressing home - so not actually closing it) I couldn't get it to open again. I got a couple unresponsive messages asking me to force quit it, and so I finally did.

OK, so the app must have hung. I'm not sure why it did that for you, but I've seen it happen when polling was done too often. At the default of 1 second polling, this might even happen

if the system was quite busy with other apps/services etc.

Just FYI, there are two ways to close the app, and with both, the audio will continue unless you use the power off function. The first way is to use the Menu button and select "Stop this application".

The other way is via the debug mode; this is the same except it ensures any daemon is killed if running.

>Now its still playing... I went into the app and it was asking me to power it on when I was going to try the speaker option.

>I would guess that this is your API still running, while the app is just an interface? I'll probably go and attempt to stop your API via system settings. I don't want radio all night. =p

>EDIT: crap! There's nothing to force stop in terms of the APK and API... and I even turned Bluetooth off. Even unplugging my headphones doesn't work... It resumes as soon as they're back in. I guess I'll reboot my phone.

Sorry, :). As I've said, absolutely nothing needs to be running to hear FM audio. Unless you turn it off via the app, you can turn it off by disabling Android bluetooth, and possibly the WiFi

or anything else that uses the TI chip. In your case I'd bet turning WiFi off would have killed the audio.

It's also possible that hitting the volume controls would kill the audio. It does occasionally and that's a bug/limitation I have a very imperfect workaround for.

Note that the headset/speaker function in my app does not depend on bluetooth. So it can be changed even if bluetooth is off, and it also works as an audio selector

for some other apps.

Also note that unlike the stock HTC app, my app does not require the headset plugged in. Some strong stations actually come in half decent without an antenna, around 4-7 RSSI.

>But again, great start! I can't wait until things further develop. I'll keep you posted on anything I run into.

Thanks; yes, please do...

----

CM App/Open Source:

I am seriously considering getting involved with, or at least creating a fork of the CM FM app. There are many benefits to open source:

- I read a post where an individual had converted the text string resources to German, so the potential for "free" translations is nice.

- I'm greatly concerned about the software and hardware quirks of the various phones/devices that might require a lot of porting effort.

So a popular open source product is more likely to receive effort from others to do this porting work, or at least explore the issues.

- Closed source CAN generate more revenue. But open source makes it more feasible for a lone developer to compete against companies who

sell their own similar product. This is because the "lone dev" is not really alone; he likely has others assisting him, such as those

desiring different language support or those wishing to get the app ported to their device.

I'm also continuing to wonder if Google might create their own standard FM app. Once again, rumors have surfaced that Apple may release their own FM app.

Google: "Patents 20100291861 and 20100292816". Google might do the same if they can somehow make more money doing that then whatever revenue they'd

lose by people using FM instead of streaming audio. And I think the existence of a third party FM app on Android could hasten any such decision.

Regardless, an open source app has better potential to "compete" against other such apps. I.E. my work might live on, even if I ceased work on it, and even if

other alternatives arise. A similar project was undertaken on Windows Mobile and it seems to have died, along with the closed source code: http://xdaforums.com/showthread.php?t=497977