Re: Changing the sample rate of the audio device

2013/3/13 Chris Rogers <crogers@google.com>

>
> On Tue, Mar 12, 2013 at 4:43 PM, Pierre-Louis Bossart <
> pierre-louis.bossart@linux.intel.com> wrote:
>
>>
>>  Any thoughts on borrowing the "audio route change notification" design
>>> from Core Audio? On iOS, this issue looks like a problem solved without
>>> much of a fuss at the API level. Based on the kind of route change, the
>>> app may choose to rebuild its graph.
>>>
>>
>> A notification sounds good. Handling this notification to reconfigure the
>> graph should be optional though, as it may require a temporary pause in the
>> playback/capture. Only if the app believes there is a benefit to a
>> reconfiguration (lower power, better quality, better user-experience)
>> should it actually go ahead. Lower-level layers should be required to
>> handle transitions and handle automatic downmix/resampling if needed.
>> -Pierre
>>
>>
> Yes I agree it should be option, and this is the subtlety.  For many/most
> applications which don't want to go to the trouble of messy sample-rate
> changes, the audio should "just work" and playback correctly if the device
> changes sample-rate.
>
> Maybe one way to approach this is *if* an EventListener has been set on
> the AudioContext for hardware notifications, *then* the AudioContext
> sample-rate will be changed to the new hardware rate and the client code
> has a chance (in the notification) to do fancy things like re-creating the
> graph, etc.  Otherwise, if an explicit EventListener request for
> notifications has not been set, then the user agent will assume that it
> needs to handle the sample-rate change at a lower-level, keeping the
> AudioContext .sampleRate unchanged.
>
> How does that sound?
>
> Chris
>
>

Sounds like a reasonable approach to me. We want the audio output to be
uninterrupted if the audio settings change during playback. Especially in
cases where a user just plugs in headphones. But there are also situations
where we can switch to a new context if we would get a notification for
changed settings. During playback we could set a flag and create a new
context as soon as possible. For example when the user stops playback.

Jan