Re: Changing the sample rate of the audio device

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. 

-Kumar

On 12 Mar, 2013, at 5:56 AM, Jean-Charles JC Verdié <jc.verdie@mstarsemi.com> wrote:

>> 	Pierre-Louis Bossart	11March 2013 5:42 PM
>>>     Is there anything I can do about this in an application using Web 
>>>     Audio API? Is there a way to detect the changed settings? Or is it 
>>>     just a deficiency in WebKit? 
>> 
>>> This is really something to be handled at the user-agent level.  For 
>>> example, if an <audio> element is playing under the same circumstances 
>>> then it would be expected to adapt to the new hardware sample-rate.  So 
>>> ideally we'd like to have the AudioContext continue playing, adapting to 
>>> the new hardware internally.  I think it would be best in these types of 
>>> cases for the AudioContext to continue to operate at the sample-rate it 
>>> was created with, and that the user-agent simply does the appropriate 
>>> sample-rate conversion. 
>> 
>> Is there really a consensus on this? 
>> When changing accessories, both sampling rate and max number of channels can change. If the sampling rate change is handled internally, would the change in # of channels be hidden as well? Changing channels mostly has an impact on virtualization and 3D positioning, you wouldn't use the same settings and algorithms when switching from headset to speakers. 
>> -Pierre 
> 
> I would tend to disagree with the suggestion. I can reproduce the problem with an external DAC with a 96Khz sample rate. The very idea of having external decoder (whether it's a DAC or a home cinema or whatever) is to get a better decoding and rendering of the audio file being played. If we ask the browser to upsample from 44.1 whatever we can get as an output, it would be a huge loss in quality. Unless we  reverse the paradigm and work at 96 all the time and downscale to the actual value of the existing hardware... which means more cpu usage. 
> IMHO the ideal way would be to get a notification from the browser of the decoder capabilities so that the code can be adapted accordingly. Plus, as Pierre mentions, in addition to raw sample rate, there are many others settings from a digital converter that are worth knowing.
> 
> 
> Best regards
> JC Verdié
> 
>> 
>> 
>> 	Chris Rogers	6March 2013 10:22 PM
>> 
>> 
>> Hello,
>> 
>> when I run the following code and then change the audio output device to a device with a different sample rate the sound is distorted.
>> 
>> var context = new webkitAudioContext();
>> var gain = context.createGainNode();
>> gain.gain.value = 0.05;
>> var osc = context.createOscillator();
>> osc.type = 0;
>> osc.frequency.value = 440;
>> osc.connect(gain);
>> gain.connect(context.destination);
>> osc.noteOn(0);
>> 
>> http://jsfiddle.net/cQswX/1/
>> 
>> Even if I create a new context in the same tab after I changed the output device the sound is still distorted. Only after I opened a new tab (in Chrome) Web Audio API seems to adapt to the new settings.
>> 
>> I noticed this behavior when I plugged in head phones to my notebook which is connected to a Cinema Display. The display audio device has a sample rate of 48 kHz. The internal device has 44.1 kHz. The display was the initial output device. When I plugged in the head phone the output switched to the internal audio device. When I started playback the audio was distorted.
>> 
>> Is there anything I can do about this in an application using Web Audio API? Is there a way to detect the changed settings? Or is it just a deficiency in WebKit?
>> 
>> Best regards
>> 
>> Jan
>> 
>> This is really something to be handled at the user-agent level.  For example, if an <audio> element is playing under the same circumstances then it would be expected to adapt to the new hardware sample-rate.  So ideally we'd like to have the AudioContext continue playing, adapting to the new hardware internally.  I think it would be best in these types of cases for the AudioContext to continue to operate at the sample-rate it was created with, and that the user-agent simply does the appropriate sample-rate conversion.
>> 
>> Chrome doesn't do anything fancy yet to adapt as I describe, so that's probably why you were experiencing problems...
>> 
>> Chris
>> 
>> 	Jan Deinhard	6March 2013 10:32 AM
>> Hello,
>> 
>> when I run the following code and then change the audio output device to a device with a different sample rate the sound is distorted.
>> 
>> var context = new webkitAudioContext();
>> var gain = context.createGainNode();
>> gain.gain.value = 0.05;
>> var osc = context.createOscillator();
>> osc.type = 0;
>> osc.frequency.value = 440;
>> osc.connect(gain);
>> gain.connect(context.destination);
>> osc.noteOn(0);
>> 
>> http://jsfiddle.net/cQswX/1/
>> 
>> Even if I create a new context in the same tab after I changed the output device the sound is still distorted. Only after I opened a new tab (in Chrome) Web Audio API seems to adapt to the new settings.
>> 
>> I noticed this behavior when I plugged in head phones to my notebook which is connected to a Cinema Display. The display audio device has a sample rate of 48 kHz. The internal device has 44.1 kHz. The display was the initial output device. When I plugged in the head phone the output switched to the internal audio device. When I started playback the audio was distorted.
>> 
>> Is there anything I can do about this in an application using Web Audio API? Is there a way to detect the changed settings? Or is it just a deficiency in WebKit?
>> 
>> Best regards
>> 
>> Jan
> 
>