WebFM API proposals V2

Showing 1-32 of 32 messages
WebFM API proposals V2 pzhang 6/4/12 7:45 AM
I have received a lot of comments, thank you guys! Based on the
feedbacks, I made some changes:
   - renamed "isOn" to "enabled", just like other APIs
   - collapsed "onpoweron" and "onpoweroff" into "onpowerchanged", here
is the sample code:
/navigator.fm.onpowerchanged = function() {
            var enabled = navigator.fm.enabled;
            // change the style of switch element
            document.getElementById('switch').className = enabled ?
"switch-on" : "switch-off";
          };/
   - collapsed "onantennaavailable" and "onantennaunavailable" into
"onantennachanged", here is the sample code:
/navigator.fm.onantennachanged = function() {
           if (navigator.fm.antennaAvailable) {
              // warn user
              showWarnMessage("Check the antenna please.");
           } else {
              hideWarnMessage();
           }
         };/
   - added the readonly attribute "frequency", here is the sample code:
         navigator.fm.onfrequencychanged = function() {
           var frequency = navigator.fm.frequency;
           // Update the UI element
           updateUIFrequency(navigator.fm.frequency);
         };
   - changed the type of frequency to double, and the unit is MHZ
   - removed the interface "getFmURI". It is probably to be implemented
as a subtype of MediaStream[4], it is not necessary to keep this.

here is the updated IDL:

interface FM : EventTarget
{
   /* Indicate if FM is power on or off */
   readonly attribute boolean enabled;

   /* Indicate if antenna is available or not */
   readonly attribute boolean antennaAvailable;

   /* Current frequency, the unit is MHZ. The value will be 0 or the
last frequency if FM is not enabled. */
   readonly attribute double frequency;

   /* Fired when the power status of FM HW is changed */
   attribute Function onpowerchanged;

   /* Fired when the state of antenna is changed */
   attribute Function onantennachanged;

   /* Fired when FM frequency is changed. */
   attribute Function onfrequencychanged;

   /* Power on/off the FM device, onpowerchanged will be fired
accordingly */
   DOMRequest setEnabled(in bool enabled);

   /*
    onsuccess will be triggered if frequency is set successfully.
    The frequency may not be the value passed, for example: the frequency
    is out of the range, app should listen on the "onfreqchanged" to get
the right frequency.
    */
   DOMRequest setFrequency(in double frequency);

   /*
    Tell FM to seek up, if frequency is changed, onfrequencychanged will
be triggered.
    */
   DOMRequest seekUp();

   /*
    Tell FM to seek down, if frequency is changed, onfrequencychanged
will be triggered.
    */
   DOMRequest seekDown();

   /* Cancel seek action */
   DOMRequest cancelSeek();
}

There are still some concerns:
   - Should this API cover AM/HD/DAB etc.? (McCormac & Lars)
       Maybe we should consider the AM, though i haven't seen any AM app
on mobile phone, there is some chips support both FM and AM.
   - Should the interfaces related to power be defined in setttings API
? (Mounir)
       Other APIs like wifi, they also have setEnabled interface, it is
a kind of conversion as Philipp said.
   - How about the SeekRequest.cancel() instead of cancelSeek() ? (Mounir)

Let's start a new thread from here. Any comments or suggestions are
welcomed!


[4]: http://dev.w3.org/2011/webrtc/editor/getusermedia.html

On Monday, May 21, 2012 10:43:00 PM UTC+8, Pin Zhang wrote:
 > For a FM app[1], i think these features are required:
 >   1) Display the availability of the device
 >   2) Indicator of FM device status, e.g. on or off
 >   3) Notify user if the antenna is plugged or unplugged
 >   4) Manually change the radio frequency
 >   5) Display the current frequency
 >   6) Display the range of radio frequencies
 >   7) Location selection, e.g. be able to change the range of
 > frequencies based on the location
 >   8) Auto scan available radio program, up and down
 >   9) Cancel radio program seeking
 >   10) Record the sound of FM
 >
 > No.7 will not be frequently used feature, and usually, there are only
 > three options for FM band[2]:
 >   - 87500KHZ~108000KHZ (Europe and Africa)
 >   - 88000KHZ~108000KHZ (America)
 >   - 76000KHZ~90000KHZ (Japan)
 > So, define the FM band in the Settings API would be more appropriate.
 >
 > Based on these features, here are the api descriptions:
 > interface FM : EventTarget
 > {
 >   /* Indicate if FM is on */
 >   readonly attribute boolean isOn;
 >
 >   /* Indicate if antenna is available */
 >   readonly attribute boolean isAntennaAvailable;
 >
 >   /* Fired when antenna is plugged */
 >   attribute Function onantennaavailable;
 >
 >   /* Fired when antenna is unplugged */
 >   attribute Function onantennaunavailable;
 >
 >   /* Fired when FM HW is power on */
 >   attribute Function onpoweron;
 >
 >   /* Fired when FM HW is power off */
 >   attribute Function onpoweroff;
 >
 >   /*
 >    Fired when FM frequency is changed. The current frequency will be
 > returned as the freq of event object.
 >    */
 >   attribute Function onfreqchanged;
 >
 >   /* Turn on the FM, onsuccess will be triggered if FM is turned on.
 > */
 >   DOMRequest on();
 >
 >   /* Turn off the FM */
 >   DOMRequest off();
 >
 >   /* Current frequncy will be returned as result of request */
 >   DOMRequest getFreq();
 >
 >   /*
 >    onsuccess will be triggered if frequency is set successfully.
 >    The frequency may not be the value passed, for example: the freq is
 > out of the range, app should listen on the "onfreqchanged" to get the
 > right frequency.
 >    */
 >   DOMRequest setFreq(in long freq);
 >
 >   /*
 >    Tell FM seek up, the next frequency will be returned as result of
 > request, in the mean time,
 >    if frequency is changed, onfreqchanged will be triggered.
 >    */
 >   DOMRequest seekUp();
 >
 >   /*
 >    Tell FM seek down, the next frequency will be returned as result of
 > request, in the mean time,
 >    if frequency is changed, onfreqchanged will be triggered.
 >    */
 >   DOMRequest seekDown();
 >
 >   /* Cancel seek action */
 >   DOMRequest cancelSeek();
 >
 >   /* FM media API */
 >   DOMString getFmURI();
 > }
 >
 > Here are some examples:
 >   // Add frequency changed event listener
 >   window.navigator.fm.onfreqchanged = function(event) {
 >     var freq = event.freq;
 >     // Update UI element
 >     updateUIFreq(freq);
 >   };
 >
 >   // get frequency
 >   var request = window.navigator.fm.getFreq();
 >   request.onsuccess = function() {
 >     // update UI element
 >     updateUIFreq(request.result);
 >   };
 >
 >   request.onerror = function() {
 >     // display alarm
 >     displayAlarm("Failed to get frequency.");
 >   };
 >
 > Most of the functions are asynchronous and return a DOMRequest object,
 > because any of the function call may fail, for example: it will fail
 > to get or set frequency if FM HW is power off.
 >
 > For the RDS (Radio Data System)[3], I think it's not the top priority
 > feature, we could define another interface for RDS after we finished
 > the WebFM API.
 >
 > Any comments and suggestions are welcomed.
 >
 > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=749053
 > [2]: http://en.wikipedia.org/wiki/FM_broadcast_band
 > [3]: http://en.wikipedia.org/wiki/Radio_Data_System

Re: WebFM API proposals V2 Andy Buckingham (RadioDNS) 6/6/12 8:53 AM
I'm new to this thread but I thought I'd cross post something I probably put in the wrong place over at bugzilla.

I note the introduction of support for FM radio in to B2G with great interest and would like to draw your interest to a couple of interesting projects.

Firstly, a group of broadcasters from across the world are forming a discussion group surrounding the harmonisation of FM/HD/DAB radio access in mobile devices, to ensure stable and reliable 3rd party software implementations utilising the radio hardware in devices. It would be great to open discussions with you regarding this work to and you would be best contacting the chair person of this project, message me I can provide you with introductions.

Secondly, with regards to the FM application on B2G I'd like to inform you about a project called RadioDNS (http://radiodns.org) which provides a free, open, non-proprietary technology platform to build hybrid radio applications upon which can link received FM/DAB/HD radio to IP-based services. For example, RadioVIS is an application built on top of RadioDNS which allows the rich colour screen of a mobile device to be populated by relevant visuals and short text messages from the broadcaster, in synchronisation with the broadcast audio allowing for a more app-like experience than a large "87.8 FM" display. You can find out loads more information on the website above, or feel free to reach out to me for any additional information.

Specific to this discussion on FM radio support in the WebAPI I'd definitely add a vote for a reasonable level of RDS support in the core. Without such it's difficult to implement something like RadioDNS which opens the door to some clever applications with broadcast radio.


Andy.
unk...@googlegroups.com 6/6/12 8:53 AM <This message has been deleted.>
Re: WebFM API proposals V2 Jonas Sicking 6/7/12 1:30 AM
In general the API looks great! A few comments below.

> interface FM : EventTarget
> {
>  /* Indicate if FM is power on or off */
>  readonly attribute boolean enabled;
>
>  /* Indicate if antenna is available or not */
>  readonly attribute boolean antennaAvailable;

Is this for things like external antennas?

>  /* Current frequency, the unit is MHZ. The value will be 0 or the last
> frequency if FM is not enabled. */
>  readonly attribute double frequency;
>
>  /* Fired when the power status of FM HW is changed */
>  attribute Function onpowerchanged;

Does this basically indicate if the .enabled property changes? I.e.
are "power" and "enabled" somehow different?

If they are the same thing then it might be easier for the page to
have two separate events (sorry, I see that you recently switched to
having one event). I.e. to have something like onenabled and
ondisabled. Otherwise you end up with code looking like:

radio.onpowerchanged = function() {
  if (radio.enabled) {
    enableRadioControlUI();
  }
  else {
    disableRadioControlUI();
  }
}

I.e. it's likely that very little code will be changed between the
"radio was turned on" and the "radio was turned off" code paths. So it
would be cleaner for the page to do something like:

radio.onenabled = enableRadioControUI;
radio.ondisabled = disableRadioControUI;

>  /* Fired when the state of antenna is changed */
>  attribute Function onantennachanged;
>
>  /* Fired when FM frequency is changed. */
>  attribute Function onfrequencychanged;

Do we also need to expose the signal strength? Or at least expose
whether we have a good signal or not.

>  /* Power on/off the FM device, onpowerchanged will be fired accordingly */
>  DOMRequest setEnabled(in bool enabled);
>
>  /*
>   onsuccess will be triggered if frequency is set successfully.
>   The frequency may not be the value passed, for example: the frequency
>   is out of the range, app should listen on the "onfreqchanged" to get the
> right frequency.
>   */
>  DOMRequest setFrequency(in double frequency);
>
>  /*
>   Tell FM to seek up, if frequency is changed, onfrequencychanged will be
> triggered.
>   */
>  DOMRequest seekUp();
>
>  /*
>   Tell FM to seek down, if frequency is changed, onfrequencychanged will be
> triggered.
>   */
>  DOMRequest seekDown();
>
>  /* Cancel seek action */
>  DOMRequest cancelSeek();

I think this can simply return void. And then we'd fire an 'error'
event on the DOMRequest returned from the seekUp/Down function.

>  - Should the interfaces related to power be defined in setttings API ?

I think using a setting only makes sense if the power state should be
remembered if the phone is restarted.

Is the intent that the radio would remain on even if the user quits
the radio player app?

>  - How about the SeekRequest.cancel() instead of cancelSeek() ? (Mounir)

I think either is fine.

/ Jonas
Re: WebFM API proposals V2 pzhang 6/8/12 7:42 PM
Thank you for your comments,  see my replies below pls.

BTW, what your options of the suggestion about covering AM/DAB/HD etc.?

On 06/07/2012 04:30 PM, Jonas Sicking wrote:
> In general the API looks great! A few comments below.
>
>> interface FM : EventTarget
>> {
>>   /* Indicate if FM is power on or off */
>>   readonly attribute boolean enabled;
>>
>>   /* Indicate if antenna is available or not */
>>   readonly attribute boolean antennaAvailable;
> Is this for things like external antennas?
Most phones use headset as external antenna, so app should be notified
when headset is plugged or unplugged.
>
>>   /* Current frequency, the unit is MHZ. The value will be 0 or the last
>> frequency if FM is not enabled. */
>>   readonly attribute double frequency;
>>
>>   /* Fired when the power status of FM HW is changed */
>>   attribute Function onpowerchanged;
> Does this basically indicate if the .enabled property changes? I.e.
> are "power" and "enabled" somehow different?
Yes, they are the same thing.
>
> If they are the same thing then it might be easier for the page to
> have two separate events (sorry, I see that you recently switched to
> having one event). I.e. to have something like onenabled and
> ondisabled. Otherwise you end up with code looking like:
>
> radio.onpowerchanged = function() {
>    if (radio.enabled) {
>      enableRadioControlUI();
>    }
>    else {
>      disableRadioControlUI();
>    }
> }
>
> I.e. it's likely that very little code will be changed between the
> "radio was turned on" and the "radio was turned off" code paths. So it
> would be cleaner for the page to do something like:
>
> radio.onenabled = enableRadioControUI;
> radio.ondisabled = disableRadioControUI;
Using two events or on event are fine to me, but "enabled" and
"onenabled" are more intuitively connected than "onpowerchanged".
>>   /* Fired when the state of antenna is changed */
>>   attribute Function onantennachanged;
>>
>>   /* Fired when FM frequency is changed. */
>>   attribute Function onfrequencychanged;
> Do we also need to expose the signal strength? Or at least expose
> whether we have a good signal or not.
Good idea, but I am not sure if the FM chips support this, let me figure
it out first.
>>   /* Power on/off the FM device, onpowerchanged will be fired accordingly */
>>   DOMRequest setEnabled(in bool enabled);
>>
>>   /*
>>    onsuccess will be triggered if frequency is set successfully.
>>    The frequency may not be the value passed, for example: the frequency
>>    is out of the range, app should listen on the "onfreqchanged" to get the
>> right frequency.
>>    */
>>   DOMRequest setFrequency(in double frequency);
>>
>>   /*
>>    Tell FM to seek up, if frequency is changed, onfrequencychanged will be
>> triggered.
>>    */
>>   DOMRequest seekUp();
>>
>>   /*
>>    Tell FM to seek down, if frequency is changed, onfrequencychanged will be
>> triggered.
>>    */
>>   DOMRequest seekDown();
>>
>>   /* Cancel seek action */
>>   DOMRequest cancelSeek();
> I think this can simply return void. And then we'd fire an 'error'
> event on the DOMRequest returned from the seekUp/Down function.
I am afraid it is hard to be implemented like this, when i do
implementation (for Galaxy-s2, Si4709 fm chip), if i cancel seek, the
action of seeking will stop at a frequency successfully, even though
there is no signal for the frequency.
>>   - Should the interfaces related to power be defined in setttings API ?
> I think using a setting only makes sense if the power state should be
> remembered if the phone is restarted.
I don't think it is necessary.
> Is the intent that the radio would remain on even if the user quits
> the radio player app?
There are some FM apps which provide a setting about whether keep FM
when quit app, i think some users might prefer keep FM, but this can be
implmented as an in-app setting instead of Settings API, i.e., whether
call "setEnabled(false)" when window is unloaded.
Re: WebFM API proposals V2 pzhang 6/8/12 7:51 PM
Thanks for your information, this is not only about a FM application on
B2G project, it is more about an open standard that need other
browsers/platforms agree to support, so i think we should keep this API
as simple and clear as possible.

-----
Pin Zhang
>> interface FM : EventTarget
>> {
>>     /* Indicate if FM is power on or off */
>>     readonly attribute boolean enabled;
>>
>>     /* Indicate if antenna is available or not */
>>     readonly attribute boolean antennaAvailable;
>>
>>     /* Current frequency, the unit is MHZ. The value will be 0 or the
>> last frequency if FM is not enabled. */
>>     readonly attribute double frequency;
>>
>>     /* Fired when the power status of FM HW is changed */
>>     attribute Function onpowerchanged;
>>
>>     /* Fired when the state of antenna is changed */
>>     attribute Function onantennachanged;
>>
>>     /* Fired when FM frequency is changed. */
>>     attribute Function onfrequencychanged;
>>
>>     /* Power on/off the FM device, onpowerchanged will be fired
>> accordingly */
>>     DOMRequest setEnabled(in bool enabled);
>>
>>     /*
>>      onsuccess will be triggered if frequency is set successfully.
>>      The frequency may not be the value passed, for example: the frequency
>>      is out of the range, app should listen on the "onfreqchanged" to get
>> the right frequency.
>>      */
>>     DOMRequest setFrequency(in double frequency);
>>
>>     /*
>>      Tell FM to seek up, if frequency is changed, onfrequencychanged will
>> be triggered.
>>      */
>>     DOMRequest seekUp();
>>
>>     /*
>>      Tell FM to seek down, if frequency is changed, onfrequencychanged
>> will be triggered.
>>      */
>>     DOMRequest seekDown();
>>
>>     /* Cancel seek action */
>>     DOMRequest cancelSeek();
>> }
>>
>> There are still some concerns:
>>     - Should this API cover AM/HD/DAB etc.? (McCormac&  Lars)
>>         Maybe we should consider the AM, though i haven't seen any AM app
>> on mobile phone, there is some chips support both FM and AM.
>>     - Should the interfaces related to power be defined in setttings API
>> ? (Mounir)
>>         Other APIs like wifi, they also have setEnabled interface, it is
>> a kind of conversion as Philipp said.
>>     - How about the SeekRequest.cancel() instead of cancelSeek() ? (Mounir)
>>
>> Let's start a new thread from here. Any comments or suggestions are
>> welcomed!
>>
>>
>> [4]: http://dev.w3.org/2011/webrtc/editor/getusermedia.html
>>
>> On Monday, May 21, 2012 10:43:00 PM UTC+8, Pin Zhang wrote:
>>   >  For a FM app[1], i think these features are required:
>>   >    1) Display the availability of the device
>>   >    2) Indicator of FM device status, e.g. on or off
>>   >    3) Notify user if the antenna is plugged or unplugged
>>   >    4) Manually change the radio frequency
>>   >    5) Display the current frequency
>>   >    6) Display the range of radio frequencies
>>   >    7) Location selection, e.g. be able to change the range of
>>   >  frequencies based on the location
>>   >    8) Auto scan available radio program, up and down
>>   >    9) Cancel radio program seeking
>>   >    10) Record the sound of FM
>>   >
>>   >  No.7 will not be frequently used feature, and usually, there are only
>>   >  three options for FM band[2]:
>>   >    - 87500KHZ~108000KHZ (Europe and Africa)
>>   >    - 88000KHZ~108000KHZ (America)
>>   >    - 76000KHZ~90000KHZ (Japan)
>>   >  So, define the FM band in the Settings API would be more appropriate.
>>   >
>>   >  Based on these features, here are the api descriptions:
>>   >  interface FM : EventTarget
>>   >  {
>>   >    /* Indicate if FM is on */
>>   >    readonly attribute boolean isOn;
>>   >
>>   >    /* Indicate if antenna is available */
>>   >    readonly attribute boolean isAntennaAvailable;
>>   >
>>   >    /* Fired when antenna is plugged */
>>   >    attribute Function onantennaavailable;
>>   >
>>   >    /* Fired when antenna is unplugged */
>>   >    attribute Function onantennaunavailable;
>>   >
>>   >    /* Fired when FM HW is power on */
>>   >    attribute Function onpoweron;
>>   >
>>   >    /* Fired when FM HW is power off */
>>   >    attribute Function onpoweroff;
>>   >
>>   >    /*
>>   >     Fired when FM frequency is changed. The current frequency will be
>>   >  returned as the freq of event object.
>>   >     */
>>   >    attribute Function onfreqchanged;
>>   >
>>   >    /* Turn on the FM, onsuccess will be triggered if FM is turned on.
>>   >  */
>>   >    DOMRequest on();
>>   >
>>   >    /* Turn off the FM */
>>   >    DOMRequest off();
>>   >
>>   >    /* Current frequncy will be returned as result of request */
>>   >    DOMRequest getFreq();
>>   >
>>   >    /*
>>   >     onsuccess will be triggered if frequency is set successfully.
>>   >     The frequency may not be the value passed, for example: the freq is
>>   >  out of the range, app should listen on the "onfreqchanged" to get the
>>   >  right frequency.
>>   >     */
>>   >    DOMRequest setFreq(in long freq);
>>   >
>>   >    /*
>>   >     Tell FM seek up, the next frequency will be returned as result of
>>   >  request, in the mean time,
>>   >     if frequency is changed, onfreqchanged will be triggered.
>>   >     */
>>   >    DOMRequest seekUp();
>>   >
>>   >    /*
>>   >     Tell FM seek down, the next frequency will be returned as result of
>>   >  request, in the mean time,
>>   >     if frequency is changed, onfreqchanged will be triggered.
>>   >     */
>>   >    DOMRequest seekDown();
>>   >
>>   >    /* Cancel seek action */
>>   >    DOMRequest cancelSeek();
>>   >
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
Re: WebFM API proposals V2 Jonas Sicking 6/9/12 8:33 AM
On Sat, Jun 9, 2012 at 3:42 AM, pzhang <pzh...@mozilla.com> wrote:
> Thank you for your comments,  see my replies below pls.
>
> BTW, what your options of the suggestion about covering AM/DAB/HD etc.?

I don't feel that I know enough to have a strong opinion. But it does
seem worth supporting. Would simply adding something like

  ...
  DOMString band;
  attribute Function onbandchange;
  DOMRequest setBand(DOMString band, double frequency);
  ...

work?

> On 06/07/2012 04:30 PM, Jonas Sicking wrote:
>>
>> In general the API looks great! A few comments below.
>>
>>> interface FM : EventTarget
>>> {
>>>  /* Indicate if FM is power on or off */
>>>  readonly attribute boolean enabled;
>>>
>>>  /* Indicate if antenna is available or not */
>>>  readonly attribute boolean antennaAvailable;
>>
>> Is this for things like external antennas?
>
> Most phones use headset as external antenna, so app should be notified when
> headset is plugged or unplugged.

Sounds good.

>>>  /* Current frequency, the unit is MHZ. The value will be 0 or the last
>>> frequency if FM is not enabled. */
>>>  readonly attribute double frequency;
>>>
>>>  /* Fired when the power status of FM HW is changed */
>>>  attribute Function onpowerchanged;
>>
>> Does this basically indicate if the .enabled property changes? I.e.
>> are "power" and "enabled" somehow different?
>
> Yes, they are the same thing.
>
>>
>> If they are the same thing then it might be easier for the page to
>> have two separate events (sorry, I see that you recently switched to
>> having one event). I.e. to have something like onenabled and
>> ondisabled. Otherwise you end up with code looking like:
>>
>> radio.onpowerchanged = function() {
>>   if (radio.enabled) {
>>     enableRadioControlUI();
>>   }
>>   else {
>>     disableRadioControlUI();
>>   }
>> }
>>
>> I.e. it's likely that very little code will be changed between the
>> "radio was turned on" and the "radio was turned off" code paths. So it
>> would be cleaner for the page to do something like:
>>
>> radio.onenabled = enableRadioControUI;
>> radio.ondisabled = disableRadioControUI;
>
> Using two events or on event are fine to me, but "enabled" and "onenabled"
> are more intuitively connected than "onpowerchanged".

Cool. I'd say let's go with onenabled and ondisabled as events, and
enabled as property then.

>>>  /* Fired when the state of antenna is changed */
>>>  attribute Function onantennachanged;
>>>
>>>  /* Fired when FM frequency is changed. */
>>>  attribute Function onfrequencychanged;

I missed this before, but these to should be named onantennachange and
onfrequencychange in order to match events like onreadystatechange.

>> Do we also need to expose the signal strength? Or at least expose
>> whether we have a good signal or not.
>
> Good idea, but I am not sure if the FM chips support this, let me figure it
> out first.

Sounds good.

>>>  /* Power on/off the FM device, onpowerchanged will be fired accordingly
>>> */
>>>  DOMRequest setEnabled(in bool enabled);
>>>
>>>  /*
>>>   onsuccess will be triggered if frequency is set successfully.
>>>   The frequency may not be the value passed, for example: the frequency
>>>   is out of the range, app should listen on the "onfreqchanged" to get
>>> the
>>> right frequency.
>>>   */
>>>  DOMRequest setFrequency(in double frequency);
>>>
>>>  /*
>>>   Tell FM to seek up, if frequency is changed, onfrequencychanged will be
>>> triggered.
>>>   */
>>>  DOMRequest seekUp();
>>>
>>>  /*
>>>   Tell FM to seek down, if frequency is changed, onfrequencychanged will
>>> be
>>> triggered.
>>>   */
>>>  DOMRequest seekDown();
>>>
>>>  /* Cancel seek action */
>>>  DOMRequest cancelSeek();
>>
>> I think this can simply return void. And then we'd fire an 'error'
>> event on the DOMRequest returned from the seekUp/Down function.
>
> I am afraid it is hard to be implemented like this, when i do implementation
> (for Galaxy-s2, Si4709 fm chip), if i cancel seek, the action of seeking
> will stop at a frequency successfully, even though there is no signal for
> the frequency.

Hmm.. One option would be to remember the initial frequency when
seekUp/Down is called and then restore that when cancelSeek is called.
But I assume there's a risk that restoring would produce an error
which could make things very confusing?

You could still make cancelSeek return void but produce an error in
the DOMRequest corresponding to the seekUp/Down call. We'd still be
firing onfrequencychange so the app will still know what is happening.

>>>  - Should the interfaces related to power be defined in setttings API ?
>>
>> I think using a setting only makes sense if the power state should be
>> remembered if the phone is restarted.
>
> I don't think it is necessary.

Then I'd say we shouldn't keep the power information in the settings API.

>> Is the intent that the radio would remain on even if the user quits
>> the radio player app?
>
> There are some FM apps which provide a setting about whether keep FM when
> quit app, i think some users might prefer keep FM, but this can be
> implmented as an in-app setting instead of Settings API, i.e., whether call
> "setEnabled(false)" when window is unloaded.

The question really is if we should *allow* the radio to stay on
longer than the app which turned it on. One problem with allowing this
is that we end up in a problematic situation if the radio app crashes
since the radio would still be on and we wouldn't know if we should
turn it off or not.

The alternative is that we automatically turn off the radio whenever
the app which turned it off is shut down or crashes. That would be
similar to how an internet radio app works for example. The app can
still stay awake in the background by grabbing the appropriate
wake-locks. as to allow playing radio in the background.

But I'd also be ok with allowing the radio to stay on past application
shutdown for now. If it turns out to be a problem we can always change
it later.

/ Jonas
Re: WebFM API proposals V2 Andy Buckingham (RadioDNS) 6/11/12 1:52 AM
On Saturday, June 9, 2012 3:51:34 AM UTC+1, pzhang wrote:
> Thanks for your information, this is not only about a FM application on
> B2G project, it is more about an open standard that need other
> browsers/platforms agree to support, so i think we should keep this API
> as simple and clear as possible.

Thanks for the clarification.

I would strongly urge the consideration of a minimal set of identifying parameters be forwarded from any radio hardware in the device, to allow subsequent apps to be built on top of the core API.

For example an FM API should provide RDS ECC, PI and PS values from the FM hardware (where available). Likewise HD Radio should send the transmitted facility code and DAB the ECC, EId, SId and SCIdS values.

Without these values, it's hard for any application to determine what radio service is being consumed.
unk...@googlegroups.com 6/11/12 1:52 AM <This message has been deleted.>
Re: WebFM API proposals V2 pzhang 6/11/12 7:00 AM


On 06/09/2012 11:33 PM, Jonas Sicking wrote:
> On Sat, Jun 9, 2012 at 3:42 AM, pzhang<pzh...@mozilla.com>  wrote:
>> Thank you for your comments,  see my replies below pls.
>>
>> BTW, what your options of the suggestion about covering AM/DAB/HD etc.?
> I don't feel that I know enough to have a strong opinion. But it does
> seem worth supporting. Would simply adding something like
>
>    ...
>    DOMString band;
>    attribute Function onbandchange;
>    DOMRequest setBand(DOMString band, double frequency);
>    ...
>
> work?
>
Is the band you mentioned here one of FM/AM/HD etc.? Not the range of
frequencies (http://en.wikipedia.org/wiki/FM_broadcast_band) ?

For DAB
(http://en.wikipedia.org/wiki/Digital_Audio_Broadcasting#Bands_and_modes),
there should be not only band settings but also modes.
And there are other digital radios: FmeXtra, HD Radio, DRM, CAM-D, i
think it would be too complicated to cover all types of radios.

How about only cover FM and AM in this API?

For FM band (range of frequencies), according to the wiki page, there
are only three options:
   - 87.5 MHZ~108MHZ (Europe and Africa)
   - 88    MHZ~108MHZ (America)
   - 76    MHZ~90  MHZ (Japan)
take the FM chip Si4709 for example, it only take one of the three
constant value as band input, you can not set other customized bands
like "87MHZ-100MHZ".

For AM band
(http://en.wikipedia.org/wiki/AM_broadcasting#Broadcast_frequency_bands), there
are several options too:
   - Long wave: 148.5kHz ~ 283.5kHz
   - Medium wave: 20kHz ~ 1610kHz
   - Short wave: 2.3mHz~26.1mHz, divided into 14 broadcast bands
I don't know how the chips would support the band setting, but i think
it might be similar as the FM chips.

So we can set the radio type and band by Settings API, no more
interfaces will be introduced.

>>>>   /* Fired when the state of antenna is changed */
>>>>   attribute Function onantennachanged;
>>>>
>>>>   /* Fired when FM frequency is changed. */
>>>>   attribute Function onfrequencychanged;
> I missed this before, but these to should be named onantennachange and
> onfrequencychange in order to match events like onreadystatechange.
OK
I prefer the latter.
>>> Is the intent that the radio would remain on even if the user quits
>>> the radio player app?
>> There are some FM apps which provide a setting about whether keep FM when
>> quit app, i think some users might prefer keep FM, but this can be
>> implmented as an in-app setting instead of Settings API, i.e., whether call
>> "setEnabled(false)" when window is unloaded.
> The question really is if we should *allow* the radio to stay on
> longer than the app which turned it on. One problem with allowing this
> is that we end up in a problematic situation if the radio app crashes
> since the radio would still be on and we wouldn't know if we should
> turn it off or not.
>
> The alternative is that we automatically turn off the radio whenever
> the app which turned it off is shut down or crashes. That would be
> similar to how an internet radio app works for example. The app can
> still stay awake in the background by grabbing the appropriate
> wake-locks. as to allow playing radio in the background.
How can an web app grab a wake-lock? I have no idea about this.
Re: WebFM API proposals V2 Mounir Lamouri 6/20/12 8:37 AM
I think things would be smoother and more intuitive if there was a
cancel() method on a SeekRequestobject that would be returned from
seekDown() and seekUp(). That way, there would be no problem with
cancelSeek() being called when there is actually no seek. There would be
no problem regarding which event to send to the DOMRequest from
seek{Up,Down}(). In addition, to allow the user to cancel seeking, the
UI will have to show a button when seeking will actually happen. That
means, UI will have to keep a track of the seeking state. If that could
be done with a SeekRequest object that could be used to cancel the
request, that seems more convenient for developers.

Also, IMO, canceling a seek shouldn't revert to the previous frequency
but should just stop the frequency to be changed.

Cheers,
--
Mounir
WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/17/12 1:44 AM
Hi Jonas,

Based on your comments, here is what i changed:
   - replace onpowerchanged with onenabled and ondisabled
   - rename onfrequencychanged to onfrequencychange
   - rename onantennachanged to onantennachange
   - add readonly attribute "signalStrength"
   - add method "onsignalchange"

here is the updated IDL:

interface FM : EventTarget
{
   /* Indicate if FM is power on or off */
   readonly attribute boolean enabled;

   /* Indicate if antenna is available or not */
   readonly attribute boolean antennaAvailable;

   /* Current frequency, the unit is MHZ.
      The value will be 0 or the last frequency if FM is not enabled. */
   readonly attribute double frequency;

   /* the strength of signal */
   readonly attribute short signalStrength;

   /* Fired when the the FM is enabled */
   attribute Function onenabled;

   /* Fired when the the FM is disabled */
   attribute Function ondisabled;

   /* Fired when the state of antenna is changed */
   attribute Function onantennachange;

   /* Fired when FM frequency is changed. */
   attribute Function onfrequencychange;

   /* Fired when the strength of signal is changed. */
   attribute Function onsignalchange;

   /* Power on/off the FM device, onpowerchanged will be fired
accordingly */
   DOMRequest setEnabled(in bool enabled);

   /*
    onsuccess will be triggered if frequency is set successfully.
    The frequency may not be the value passed, for example: the
frequency  is
    out of the range, app should listen on the "onfreqchanged" to get
    the right frequency.
    */
   DOMRequest setFrequency(in double frequency);

   /*
    Tell FM to seek up, if frequency is changed,
    onfrequencychanged will be triggered.
    */
   DOMRequest seekUp();

   /*
    Tell FM to seek down, if frequency is changed,
    onfrequencychanged will be triggered.
    */
   DOMRequest seekDown();

   /* Cancel seek action */
   DOMRequest cancelSeek();
}

----------
Pin Zhang

<http://www.firefox.com.cn/>
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/17/12 12:01 PM
On Tuesday, July 17, 2012, pzhang wrote:

>  Hi Jonas,
>
> Based on your comments, here is what i changed:
>   - replace onpowerchanged with onenabled and ondisabled
>   - rename onfrequencychanged to onfrequencychange
>   - rename onantennachanged to onantennachange
>   - add readonly attribute "signalStrength"
>   - add method "onsignalchange"
>

This is looking great!
If someone requests an out-of-range frequency I think we should immediately
(but asynchronously) fire an "error" event on the DOMRequest. No need to
set the radio frequency to the closest match since that will likely not
tune in the radio station the caller wanted anyway.


>   /*
>    Tell FM to seek up, if frequency is changed,
>    onfrequencychanged will be triggered.
>    */
>   DOMRequest seekUp();
>
>   /*
>    Tell FM to seek down, if frequency is changed,
>    onfrequencychanged will be triggered.
>    */
>   DOMRequest seekDown();
>
>   /* Cancel seek action */
>   DOMRequest cancelSeek();
> }
>


*If* we want to add AM radio support too, I would suggest adding something
like

DOMString band;
attribute Function onbandchange;
DOMRequest setBand(DOMString band, double frequency);
attribute any bandRanges;

The last attribute would return a JSON object like
{
  "FM": { "lower": 87.5, "upper": 108 },
  "AM": { "lower": 0.02, "upper": 1.61 }
}

(all frequencies in MHz).

Note that we should return the ranges of the hardware chip and drivers that
the device is supporting. We shouldn't return whatever values are in
Wikipedia :-)

However waiting with adding AM support is definitely ok with me.

/ Jonas
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Justin Lebar 7/17/12 12:21 PM
> So we can set the radio type and band by Settings API, no more interfaces
> will be introduced.

I do not think we should do it like this.  FM band should be selected
on the FM API.

There are lots of reasons for this, but the simplest one is: We
shouldn't set the FM band in the settings API for the same reason we
shouldn't set the FM /frequency/ in the settings API.

If someone here thinks band selection should be on the settings API,
could they please explain why?

>  /* the strength of signal */
>  readonly attribute short signalStrength;

Is this 0-100, 0-128, something else?  I'd prefer that it was a double
in the range [0, 1], like battery strength.  But I'll note that DOM
Telephony has a signal-strength attribute in the range 0 - 100.

(DOM Telephony also has a signal strength in dBm, which seems like it
would be a sensible addition to this API.)
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/17/12 12:24 PM
On Tue, Jul 17, 2012 at 12:21 PM, Justin Lebar <justin...@gmail.com> wrote:
>> So we can set the radio type and band by Settings API, no more interfaces
>> will be introduced.
>
> I do not think we should do it like this.  FM band should be selected
> on the FM API.
>
> There are lots of reasons for this, but the simplest one is: We
> shouldn't set the FM band in the settings API for the same reason we
> shouldn't set the FM /frequency/ in the settings API.
>
> If someone here thinks band selection should be on the settings API,
> could they please explain why?

I agree. If we want to support more bands than just FM we need to add
it to the radio API.

>>  /* the strength of signal */
>>  readonly attribute short signalStrength;
>
> Is this 0-100, 0-128, something else?  I'd prefer that it was a double
> in the range [0, 1], like battery strength.  But I'll note that DOM
> Telephony has a signal-strength attribute in the range 0 - 100.

Good catch. I agree that a 0-1 float is better.

/ Jonas
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Justin Lebar 7/17/12 12:31 PM
>> If someone here thinks band selection should be on the settings API,
>> could they please explain why?
>
> I agree. If we want to support more bands than just FM we need to add
> it to the radio API.

What I meant was, "FM" has more than one set of frequency ranges; the
range that's used for radio is different around the world.

>From earlier in this thread:

> For FM band (range of frequencies), according to the wiki page, there are only
> three options:
>   - 87.5 MHZ~108MHZ (Europe and Africa)
>   - 88    MHZ~108MHZ (America)
>   - 76    MHZ~90  MHZ (Japan)
>
> take the FM chip Si4709 for example, it only take one of the three constant
> value as band input, you can not set other customized bands like "87MHZ-
> 100MHZ".

I think the API should let you select which of these ranges you want,
if h/w supports it.
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/17/12 6:03 PM
I think we're definitely talking past each other, but are in general agreement.

The way I understand things, the hardware in the phone will have some
limit in which FM frequencies that it supports. I don't think that the
hardware has different "modes" where it supports different frequency
ranges in different modes.

I think the above list is simply a table of which FM frequencies
different parts of the world license radio stations to transmit in.
It's not actually related to how radio receiver hardware in the device
operate.

Or am I wrong?

/ Jonas
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Justin Lebar 7/17/12 6:26 PM
> The way I understand things, the hardware in the phone will have some
> limit in which FM frequencies that it supports. I don't think that the
> hardware has different "modes" where it supports different frequency
> ranges in different modes.

That's not consistent with what I understood from what I quoted above,
nor what I got out of the patch I read [1].

>>> take the FM chip Si4709 for example, it only take one of the three constant
>>> value as band input, you can not set other customized bands like "87MHZ-
>>> 100MHZ".

But I am definitely not an expert on the hardware.

> I think the above list is simply a table of which FM frequencies
> different parts of the world license radio stations to transmit in.
> It's not actually related to how radio receiver hardware in the device
> operate.

Even if it is true that we could tune the radio receiver to arbitrary
frequencies, someone still needs to specify which "country band" we're
using so that e.g. seekUp() works properly.  If we don't specify the
country band, then we don't know the upper-limit for seekUp(), nor do
we know what frequency granularity to use.

[1] https://bug749053.bugzilla.mozilla.org/attachment.cgi?id=633876
Search for set_v4l2_ctrl, or even just "JAPAN".
Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/17/12 6:42 PM
my replies below

On 07/18/2012 03:01 AM, Jonas Sicking wrote:
> On Tuesday, July 17, 2012, pzhang wrote:
>
>     Hi Jonas,
>
>     Based on your comments, here is what i changed:
>       - replace onpowerchanged with onenabled and ondisabled
>       - rename onfrequencychanged to onfrequencychange
>       - rename onantennachanged to onantennachange
>       - add readonly attribute "signalStrength"
>       - add method "onsignalchange"
>
>
> This is looking great!
>
>     here is the updated IDL:
>
>     interface FM : EventTarget
>     {
>       /* Indicate if FM is power on or off */
>       readonly attribute boolean enabled;
>
>       /* Indicate if antenna is available or not */
>       readonly attribute boolean antennaAvailable;
>
>       /* Current frequency, the unit is MHZ.
>          The value will be 0 or the last frequency if FM is not
>     enabled. */
>       readonly attribute double frequency;
>
>       /* the strength of signal */
>       readonly attribute short signalStrength;
>
Agree
>
>       /*
>        Tell FM to seek up, if frequency is changed,
>        onfrequencychanged will be triggered.
>        */
>       DOMRequest seekUp();
>
>       /*
>        Tell FM to seek down, if frequency is changed,
>        onfrequencychanged will be triggered.
>        */
>       DOMRequest seekDown();
>
>       /* Cancel seek action */
>       DOMRequest cancelSeek();
>     }
>
>
>
> *If* we want to add AM radio support too, I would suggest adding
> something like
>
> DOMString band;
> attribute Function onbandchange;
> DOMRequest setBand(DOMString band, double frequency);
What is the second parameter used for? I don't quit understand.
> attribute any bandRanges;
>
> The last attribute would return a JSON object like
> {
>   "FM": { "lower": 87.5, "upper": 108 },
>   "AM": { "lower": 0.02, "upper": 1.61 }
> }
>
> (all frequencies in MHz).
>
> Note that we should return the ranges of the hardware chip and drivers
> that the device is supporting. We shouldn't return whatever values are
> in Wikipedia :-)
>
> However waiting with adding AM support is definitely ok with me.
I haven't seen a phone which support AM yet, so i prefer not supporting
in v1.
However, if we will add AM support in the future, should we keep using
the name "FM"? or change it to another name, say Radio or Broadcast,
which can cover AM?
>
> / Jonas


Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/17/12 7:01 PM
replies below

On 07/18/2012 03:21 AM, Justin Lebar wrote:
>> So we can set the radio type and band by Settings API, no more interfaces
>> will be introduced.
> I do not think we should do it like this.  FM band should be selected
> on the FM API.
>
> There are lots of reasons for this, but the simplest one is: We
> shouldn't set the FM band in the settings API for the same reason we
> shouldn't set the FM /frequency/ in the settings API.
>
> If someone here thinks band selection should be on the settings API,
> could they please explain why?
First, the band selection is not a frequently used function, and the
user may even shouldn't change the range if he/she doesn't travel around.
Second, the ranges of frequency is a determined value for the
region/country where the phone is sold,
so it is convenient for the vendor to customize if we using settings API.
>>   /* the strength of signal */
>>   readonly attribute short signalStrength;
> Is this 0-100, 0-128, something else?  I'd prefer that it was a double
> in the range [0, 1], like battery strength.  But I'll note that DOM
> Telephony has a signal-strength attribute in the range 0 - 100.
>
> (DOM Telephony also has a signal strength in dBm, which seems like it
> would be a sensible addition to this API.)
>
>>>    /*
>>>     Tell FM to seek up, if frequency is changed,
>>>     onfrequencychanged will be triggered.
>>>     */
>>>    DOMRequest seekUp();
>>>
>>>    /*
>>>     Tell FM to seek down, if frequency is changed,
>>>     onfrequencychanged will be triggered.
>>>     */
>>>    DOMRequest seekDown();
>>>
>>>    /* Cancel seek action */
>>>    DOMRequest cancelSeek();
>>> }
>>>
>>
>> *If* we want to add AM radio support too, I would suggest adding something
>> like
>>
>> DOMString band;
>> attribute Function onbandchange;
>> DOMRequest setBand(DOMString band, double frequency);
>> attribute any bandRanges;
>>
>> The last attribute would return a JSON object like
>> {
>>    "FM": { "lower": 87.5, "upper": 108 },
>>    "AM": { "lower": 0.02, "upper": 1.61 }
>> }
>>
>> (all frequencies in MHz).
>>
>> Note that we should return the ranges of the hardware chip and drivers that
>> the device is supporting. We shouldn't return whatever values are in
>> Wikipedia :-)
>>
>> However waiting with adding AM support is definitely ok with me.
>>
Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/17/12 7:53 PM
On 07/18/2012 09:26 AM, Justin Lebar wrote:
>> The way I understand things, the hardware in the phone will have some
>> limit in which FM frequencies that it supports. I don't think that the
>> hardware has different "modes" where it supports different frequency
>> ranges in different modes.
> That's not consistent with what I understood from what I quoted above,
> nor what I got out of the patch I read [1].
>
>>>> take the FM chip Si4709 for example, it only take one of the three constant
>>>> value as band input, you can not set other customized bands like "87MHZ-
>>>> 100MHZ".
> But I am definitely not an expert on the hardware.
I think your understanding is correct, the ranges of frequency can be
set to the hardware, but only several constant values is allowed.
You can also check these:
    drivers of Si4709 :
       -
https://github.com/andreasgal/GT9100-kernel/blob/master/drivers/samsung/fm_si4709/Si4709_dev.h
(line 20)
       -
https://github.com/andreasgal/GT9100-kernel/blob/master/drivers/samsung/fm_si4709/Si4709_dev.c
(line 456)
    Implementations of the radio app in CM7:
       - Si4709 (line 548):
            *
https://github.com/CyanogenMod/android_frameworks_base/blob/0620b6bb2a9b0b1d3a84fcf429609e6dba046c2e/core/jni/android_hardware_fm_si4709.cpp
       - BCM4325 (line 119):
            *
https://github.com/CyanogenMod/android_frameworks_base/blob/0620b6bb2a9b0b1d3a84fcf429609e6dba046c2e/core/jni/android_hardware_fm_bcm4325.cpp
       - WL1271 (line 132):
            *
https://github.com/CyanogenMod/android_frameworks_base/blob/0620b6bb2a9b0b1d3a84fcf429609e6dba046c2e/core/jni/android_hardware_fm_wl1271.cpp
>
>> I think the above list is simply a table of which FM frequencies
>> different parts of the world license radio stations to transmit in.
>> It's not actually related to how radio receiver hardware in the device
>> operate.
> Even if it is true that we could tune the radio receiver to arbitrary
> frequencies, someone still needs to specify which "country band" we're
> using so that e.g. seekUp() works properly.  If we don't specify the
> country band, then we don't know the upper-limit for seekUp(), nor do
> we know what frequency granularity to use.
About the frequency granularity, basically, there are three space types,
i.e. 50KHz, 100KHz and 200K, and i think we can also define it in the
settings API.
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Justin Lebar 7/17/12 8:08 PM
>> If someone here thinks band selection should be on the settings API,
>> could they please explain why?
>
> First, the band selection is not a frequently used function, and the user
> shouldn't change the range if he/she doesn't travel around.

Hm, so I guess the argument is, the band should be persisted by the
device, while we don't really care if the frequency is persisted.

That's a fair point, but I'm not entirely convinced.  There are two
possibilities here: Either the band can be modified by FM radio apps,
or not.  (I don't really know how the settings API works.)

If the band can be set by the app, then any app will have to reset the
band itself, because it can't rely on the fact that some other app
hasn't been messing with the setting.  So at that point, the band
becomes a frequently-used setting.

On the other hand, if the band can't be set by the app, then that's a
poor user experience, because the user may fire up their FM radio app
in the foreign country, and then the app will have to instruct the
user how to change the setting outside the app.

> Second, the ranges of frequency is a determined value for the region/country
> where the phone is sold,
> so it is convenient for the vendor to customize if we using settings API.

I agree that would be convenient, but given the argument above, I
don't think it works.

What would work is the vendor customizing the default FM radio app to
select the right band by default.

> About the frequency granularity, basically, there are three space types, i.e.
> 50KHz, 100KHz and 200K, and i think we can also define it in the settings API.

As a separate question: Do we want to support mismatched
band/granularity?  Or should the band entirely determine the
granularity?
Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/17/12 10:13 PM
On 07/18/2012 11:08 AM, Justin Lebar wrote:
>>> If someone here thinks band selection should be on the settings API,
>>> could they please explain why?
>> First, the band selection is not a frequently used function, and the user
>> shouldn't change the range if he/she doesn't travel around.
> Hm, so I guess the argument is, the band should be persisted by the
> device, while we don't really care if the frequency is persisted.
I am not saying that the band should be persisted by the device,
i mean we could define it in the settings API, the app can modify it,
and it is convenient for the vendor to customize too.
> That's a fair point, but I'm not entirely convinced.  There are two
> possibilities here: Either the band can be modified by FM radio apps,
> or not.  (I don't really know how the settings API works.)
The settings API just like the preference, for example:
window.navigator.mozSetting.getLock().get("keyboard.layouts.english");
you can check the Settings app in Gaia for more detailed usage cae.
> If the band can be set by the app, then any app will have to reset the
> band itself, because it can't rely on the fact that some other app
> hasn't been messing with the setting.  So at that point, the band
> becomes a frequently-used setting.
>
> On the other hand, if the band can't be set by the app, then that's a
> poor user experience, because the user may fire up their FM radio app
> in the foreign country, and then the app will have to instruct the
> user how to change the setting outside the app.
For sure, the app should have the ability to change the band.
Settings api could be used inside the APP, you can check the Settings
app in Gaia.
>> Second, the ranges of frequency is a determined value for the region/country
>> where the phone is sold,
>> so it is convenient for the vendor to customize if we using settings API.
> I agree that would be convenient, but given the argument above, I
> don't think it works.
>
> What would work is the vendor customizing the default FM radio app to
> select the right band by default.
This is an option, but it might not be a better approach, take this for
example,
if the vendor want to ship the same phone to America and Japan, they
can't just use the default FM app (http://fm.gaiamobile.org),
because the ranges of frequency of America and Japan  are different,
they have to deploy two different
fm apps with different domains.
>
>> About the frequency granularity, basically, there are three space types, i.e.
>> 50KHz, 100KHz and 200K, and i think we can also define it in the settings API.
> As a separate question: Do we want to support mismatched
> band/granularity?  Or should the band entirely determine the
> granularity?
I think the spacing type is not determined by the band, it depends on
the region/country, most of regions/countries are using
100KHz or 200KHz, few countries use 50KHz[1].
Just like the band, it could be pre-defined in the settings, and if the
user want to change it, it doesn't matter.


Actually, i don't have a strong opinion to use Settings API or introduce
more interfaces, i just want to keep the API as simple as possible, :-)
[1]: http://en.wikipedia.org/wiki/FM_broadcast_band#Center_frequencies

Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/18/12 12:45 AM
Thanks for explaining how the bands stuff works. I continue to be
amazed at how weird hardware is. Or maybe at how weird hardware
drivers are...

On Tue, Jul 17, 2012 at 10:13 PM, pzhang <pzh...@mozilla.com> wrote:
> On 07/18/2012 11:08 AM, Justin Lebar wrote:
>>>>
>>>> If someone here thinks band selection should be on the settings API,
>>>> could they please explain why?
>>>
>>> First, the band selection is not a frequently used function, and the user
>>> shouldn't change the range if he/she doesn't travel around.
>>
>> Hm, so I guess the argument is, the band should be persisted by the
>> device, while we don't really care if the frequency is persisted.
>
> I am not saying that the band should be persisted by the device,
> i mean we could define it in the settings API, the app can modify it,
> and it is convenient for the vendor to customize too.

Very few apps will have access to the settings API. Only built-in
(certified) apps will.

Basically I think it comes down to this question: Do we *need* radio
applications to be able to change bands?

Given that AM isn't supported in any hardware known to anyone in this
thread. I'm going to say that we don't care about AM bands. It will
always be possible to add support for them in the future, let's not
waste any time worrying about them for now.

That leaves FM bands. I'm going to make a call and say that I *don't*
think we should support changing FM bands from the radio app. It
introduces a bunch of complexity and it only seems important if you
are traveling to a different part of the world and want to listen to
radio there.

This means that we don't need radio apps the ability to choose a band.

Given this, we can definitely make it a setting to configure which
band is used. That way the settings app could expose this in its UI.
The band would then affect all radio apps that the user has installed.

Hence I think we can go with the API proposed in the initial email in
this thread and nothing more.

We can always add the ability to select band in a later release if
users or developers are asking for it.

/ Jonas
Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/18/12 1:08 AM
OK, it is clear enough.

One more question, as you said, only certified app can access the
settings api, and for sure the FM app is unnecessarily to be certified
(though it will be a built-in app), so how can the fm app get the value
of the band? It may effect the UI of the fm app, you can check the final
version of IxD[1], there is a dialer on which the range of frequencies
are shown.

[1]: https://wiki.mozilla.org/images/e/eb/B2g-fm-radio-v07.pdf
Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/18/12 2:15 AM
On Wed, Jul 18, 2012 at 1:08 AM, pzhang <pzh...@mozilla.com> wrote:
> OK, it is clear enough.
>
> One more question, as you said, only certified app can access the settings
> api, and for sure the FM app is unnecessarily to be certified (though it
> will be a built-in app), so how can the fm app get the value of the band? It
> may effect the UI of the fm app, you can check the final version of IxD[1],
> there is a dialer on which the range of frequencies are shown.
>
> [1]: https://wiki.mozilla.org/images/e/eb/B2g-fm-radio-v07.pdf

We can certainly expose a readonly property which describes the
available bands, which for now will only be one:

interface FMRadio {
  ...
  readonly attribute any bandRanges;
  ...
}

which would would return a JSON object like
{
  "FM": { "lower": 87.5, "upper": 108 }
}
WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/18/12 2:34 AM
Hi Jonas,

Here is the updated IDL:

interface FM : EventTarget
{
   /* Indicate if FM is power on or off */
   readonly attribute boolean enabled;

   /* Indicate if antenna is available or not */
   readonly attribute boolean antennaAvailable;

   /* Current frequency, the unit is MHZ.
      The value will be 0 or the last frequency if FM is not enabled. */
   readonly attribute double frequency;

   /* the strength of signal, the range is [0, 1] */
   readonly attribute float signalStrength;

   /* The band ranges of frequencies, it is a JSON object like
         {
            "FM": {"lower": 87.5, "upper": 108}
         }
       the unit is MHz.
   */
   readonly attribute any bandRanges;

   /* Fired when the the FM is enabled */
   attribute Function onenabled;

   /* Fired when the the FM is disabled */
   attribute Function ondisabled;

   /* Fired when the state of antenna is changed */
   attribute Function onantennachange;

   /* Fired when FM frequency is changed. */
   attribute Function onfrequencychange;

   /* Fired when the strength of signal is changed. */
   attribute Function onsignalchange;

   /* Power on/off the FM device, onpowerchanged will be fired
accordingly */
   DOMRequest setEnabled(in bool enabled);

   /*
    onsuccess will be triggered if frequency is set successfully.
    app should listen on the "onfreqchange" to get the right frequency.
    */
   DOMRequest setFrequency(in double frequency);

   /*
    Tell FM to seek up, if frequency is changed,
    onfrequencychanged will be triggered.
    */
   DOMRequest seekUp();

   /*
    Tell FM to seek down, if frequency is changed,
    onfrequencychanged will be triggered.
    */
   DOMRequest seekDown();

   /* Cancel seek action */
   DOMRequest cancelSeek();
}

----------
Pin Zhang
Re: WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/19/12 2:10 AM
Looks great!
Re: WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/19/12 5:42 PM
I think the FM app should be notified if the band ranges is changed in
settings app, so we should add one more attribute:

   /* fired if the band is changed. */
   attribute Function onbandchange;

<http://firefox.com.cn/>
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi


Re: WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 Jonas Sicking 7/19/12 10:58 PM
I'm not sure that this is worth worrying about in v1. Are we even sure
that we are going to expose UI in the settings app for selecting the
band?

/ Jonas

On Thu, Jul 19, 2012 at 5:42 PM, pzhang <pzh...@mozilla.com> wrote:
> I think the FM app should be notified if the band ranges is changed in
> settings app, so we should add one more attribute:
>
>   /* fired if the band is changed. */
>   attribute Function onbandchange;
>
>
Re: WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 pzhang 7/20/12 1:15 AM
No, i think there are no plan to add a band setting.

BTW, the final IxD[1] of FM app (v1) doesn't cover the signal strength,
should we remove the related interfaces, i.e signalStrength and
onsignalchange?

[1] https://wiki.mozilla.org/images/e/eb/B2g-fm-radio-v07.pdf

-----
Pin Zhang
Re: WebFM API proposals V4 Re: WebFM API proposals V3 Re: WebFM API proposals V2 Justin Lebar 7/20/12 7:10 AM
> BTW, the final IxD[1] of FM app (v1) doesn't cover the signal strength,
> should we remove the related interfaces, i.e signalStrength and
> onsignalchange?
>
> [1] https://wiki.mozilla.org/images/e/eb/B2g-fm-radio-v07.pdf

If the hardware exposes a signal strength, we should expose it to the
API.  Again, I think we should expose both a number in the range 0-1
and also a s/n value in dBm, if we have it.

-Justin
More topics »