Re: Changing the sample rate of the audio device

On Wed, Mar 13, 2013 at 12:53 PM, Chris Rogers <crogers@google.com> wrote:

> 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?
>

Making behavior conditional on whether an event listener has been
registered sounds bad. If we want to have varying behaviors here, explicit
control would be better.

Is there a real need to let authors respond to sample rate changes? That
seems really painful for everyone. When is it not good enough to leave the
AudioContext alone and have the browser automatically resample as needed if
the output device changes?

OTOH changing channel configuration sounds like something that is worth
exposing. But that's much easier to handle since we already have the notion
that each node has its own channel count/configuration and that can change
over time.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]