Re: Changing the sample rate of the audio device

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