FM radio proposal

[Ulf Bjorkengren]

Hi,

we at ST-Ericsson would like to propose an API for FM radio in
Android. As part of this proposal, we have integrated the API into the
existing Android media framework.
Two design documents can be found here:

https://docs.google.com/leaf?id=0Bx0OR2cNmeUrNmU2MTg4ZjAtNGNmMS00N2ExLThkYWYtMDVjMmNlMWM3Mjc5&hl=en&authkey=CIiqm7QC

https://docs.google.com/fileview?id=0Bx0OR2cNmeUrM2M5ZTNjMGQtMDk0My00NzhkLTg3YjktZDM1MmU5YTA3MmQz&hl=en&authkey=CIihg40D

Android FM radio API.tar - the auto-generated documentation of the FM
radio API. The documentation can be accessed from /doc/index.html.
Select the classes on the left hand frame to view the class specific
API in more detail.

Android FM radio SwA.ppt - an overview of the media framework modules
involved in the supported FM radio use cases.

We have successfully implemented the proposed API on hardware. We
invite any feedback and discussion on this proposal with the intention
that it leads to a solution that is shared by all involved and
contributed to Android.

Best Regards,
Ulf Bjorkengren
ST-Ericsson

[Pavan Savoy]

Hi,

Apologies if this seems naive...
The questions here are sort of general if android happens to use ALSA
for it's HAL (which I agree is not always the case...)

So most FM chipsets on linux would/should have a V4L2 interface for
the controls and alsa PCM devices for the audio.

So based on the proposal which is suggested as to how clearly we can
handle such cases where separate PCMs exist for such FM devices?
so my couple of questions are,

1. When you say a plugin/fm radio handler, does it mean it would use a
V4L2 interface?
2. Is this interface extendible to designs where we don't have a
separate pcm device for a FM device, but control using certain mixer
settings on the default device itself?
As in what constitutes a Audio Source/Sink ?

3. Is this interface proposal, involve different types of FM on
android platform architectures such as FM audio data not being routed
to apps processor at all?
(kind of related to question 2 & may eliminate recording scenario,
thereby having sort of a NULL stream on the AudioSource ... )

4. Also does this proposal have extensions where I can playback while
recording, features which phones generally don't have but media
players tend to have?

5. FM Tx cases have also been seen in very rare cases to take in
analog input, as in cases where data is not stored on a music file,
but analog input which can be from a mic, or an input which is
connected to another analog output, so those cases also tend to be
difficult if we imagine AudioSource/Sink to be PCMs right?

regards,
Pavan

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>

--
--Pavan Savoy

[Ulf Bjorkengren]

Hi Pavan,

see my answers below.

>The questions here are sort of general if android happens to use ALSA
>for it's HAL (which I agree is not always the case...)
>So most FM chipsets on linux would/should have a V4L2 interface for
>the controls and alsa PCM devices for the audio.

This FM radio proposal does not make any assumptions on whether ALSA
or V4L interfaces are used in the lower layers.

Whether ALSA is used or not is hidden beneath the
AudioHardwareInterface (indicated by the arrow between AudioFlinger
and AudioSource/AudioSink in the figure), and is a design selection by
the underlying platform vendor (through the implementation of the
AudioSource/AudioSink).

Whether V4L is used or not is hidden beneath the interface below the
FM radio handler, ), and is a design selection by the underlying
platform vendor (through the implementation of the FM radio plugin).

>1. When you say a plugin/fm radio handler, does it mean it would use a
> V4L2 interface?

The reason for the design with an FM radio handler/plugin is to allow
vendors to use different implementations on how to control their FM
radio HW. How it is implemented is abstracted within the FM radio
plugin. So using a V4L interface is one possibility, but any other
interface could be used. The interface that the plugin must implement
is the interface exposed by the FM radio handler, which basically is a
mirroring of the FM radio API. This interface is then defined within
Android, similar to the AudioHardwareInterface (if this proposal
becomes part of Android).

>2. Is this interface extendible to designs where we don't have a
>separate pcm device for a FM device, but control using certain mixer
>settings on the default device itself?

The AudioHardwareInterface handles separate devices, and does not know
anything about mixer settings. However, this interface is transparent
to how the devices are handled at layers below this interface. So in
that sense it is extendible.

>As in what constitutes a Audio Source/Sink ?

The Audio Source/Sink shown in the figures represents the device
realizations which the AudioFlinger communicates with via the
AudioHardwareInterface. They are part of the vendor specific
underlying platform, and their realization is vendor specific.

>3. Is this interface proposal, involve different types of FM on
>android platform architectures such as FM audio data not being routed
>to apps processor at all?
>(kind of related to question 2 & may eliminate recording scenario,
>thereby having sort of a NULL stream on the AudioSource ... )

In this proposal the FM audio data is routed via the Media Player /
AudioFlinger, which suggests that it is indeed routed to the apps
processor.
It is not directly extendible to an architecture where the audio data
is not routed via the apps processor. However, that does not rule out
the possibility that it can be done. A discussion on how that could be
done is welcome.

>4. Also does this proposal have extensions where I can playback while
>recording, features which phones generally don't have but media
>players tend to have?

This proposal will support simultaneous playback and recording. To
achieve this, we have added a stream splitting service in
AudioFlinger, so that both the Media Player and the Media Recorder
independently can pull data from the same source.

>5. FM Tx cases have also been seen in very rare cases to take in
>analog input, as in cases where data is not stored on a music file,
>but analog input which can be from a mic, or an input which is
>connected to another analog output, so those cases also tend to be
>difficult if we imagine AudioSource/Sink to be PCMs right?

I think this question relates to the question no 3. As this proposal
routes the FM audio data via the Media Player/AudioFlinger as a PCM
stream, the case you mention becomes indeed difficult.

Regards,
Ulf

> >https://docs.google.com/leaf?id=0Bx0OR2cNmeUrNmU2MTg4ZjAtNGNmMS00N2Ex...
>
> >https://docs.google.com/fileview?id=0Bx0OR2cNmeUrM2M5ZTNjMGQtMDk0My00...

[Ulf Bjorkengren]

The two documents describing our FM radio proposal have been updated,
see the new links below.

Android FM radio SwA.pdf:
https://docs.google.com/fileview?id=0Bx0OR2cNmeUrOWJlZjE3NDUtMjUwMi00ZGY5LTgwYzctMDg5ZWE5OWQwYWI0&hl=en&authkey=CNHnytQO
Android_FM_Radio_API.tar:
https://docs.google.com/leaf?id=0Bx0OR2cNmeUrOTdlMjBmNmEtYmMzNC00OWVlLTkwODctNjUxMTc3MGZkYjdj&hl=en&authkey=CNKxkN0J

Changelog:

Android_FM_Radio_API:
* Removed numLevels parameter from addOnScanListener on FmTransmitter
* Changed parameter signalLevel to signalStrenght in
OnScanListener.OnBlockScan() on FmTransmitter
* Removed isSignalLevelSupported
* getSignalLevel -> getSignalStrength
* Removed numLevels parameter from addOnScanListener on FmReceiver
* Removed numLevels parameter from addOnSignalLevelChanged on
FmReceiver
* Renamed addOnSignalLevelChanged -> addOnSignalStrengthChanged
* Signal levels removed and changed with signal strength that is
0-1000
* Added ERROR_CRITICAL to forced reset
* Added IOException to several methods
* Removed isReceiverEnabled, isTransmitterEnabled
* Removed setReceiverEnabled, setTransmitterEnabled
* Removed the use of AudioManager in TX
* Removed setTunerLooping
* Changed sendExtraCommand(String, Bundle) -> sendExtraCommand(String,
String[])
* Added SecurityException to start and startAsync for FmReceiver/
FmTransmitter

Android FM radio SwA:
* Clarified supported scenarios
* Added setDeviceConnection() as alternative function to set sink to
FM TX

BR,
Ulf

On 15 Okt, 15:10, Ulf Bjorkengren <ulf.bjorkeng...@stericsson.com>
wrote:

> Hi,
>
> we at ST-Ericsson would like to propose an API for FM radio in
> Android. As part of this proposal, we have integrated the API into the
> existing Android media framework.
> Two design documents can be found here:
>

> https://docs.google.com/leaf?id=0Bx0OR2cNmeUrNmU2MTg4ZjAtNGNmMS00N2Ex...
>
> https://docs.google.com/fileview?id=0Bx0OR2cNmeUrM2M5ZTNjMGQtMDk0My00...

[Arun K. Singh]

depends on what you want to hack. below api's are to develop a customer UI application for FM on STE chip unless you want something else ..

On Sun, Mar 17, 2013 at 9:43 AM, Sereno Gong <lai...@gmail.com> wrote:

ST

Best Regards,

Arun K. Singh
www.crazydaks.com