User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

See attached minimal test case, which does:

1. new AudioContext({sampleRate: 48000})
2. getUserMedia

Actual results:

"Connecting AudioNodes from AudioContexts with different sample-rate is currently not supported."

Expected results:

This limitation is self-explanatory, of course.

So I file this bug as a request for the 'enhancement', as I could find no pre-existing bugzilla entry?

But it renders the sampleRate setting of AudioContext redundant because there's no way to match an incoming stream -- there's a documented [1] constraint for the getUserMedia sample rate, but this is not implemented.

Does this mean there is even a guarantee that the default getUserMedia sample rate will match the AudioContext?

Typically this difference is going to be 44100 vs 48000Hz.

At least with getUserMedia(sampleRate) this is not a hard limitation and developers with specific requirements can work around it (and avoid resamplers)

But I note that Chromium is not limited in either so inevitibly there will be pages in the wild using this.

Thank you for the enhancement request, moving this to its component for the development team to check it out.

I think it's probably a mistake to assume this is 'enhancement'.

Because it's really a bug that means if one sets the sameRate of AudioContext then the result is unusable.

This look like a P3 to you jib?

Depends. We have both P2 and P3 bugs in this area. Paul, would this be resolved by Bug 1238038 do you think, or would more work be needed?

This is expected for now, and will be solved by fixing bug 1238038, yes. This is well underway.

Just wanted to ask how far we are in fixing this? I assume this is similar to bug 1725336 which should be fixed as well as part of fixing bug 1238038?

Tasnim, my colleague Chun-Min is quite far along already, I think it's more or less working, and I expect that we'll be able to start reviewing the patch set soon. I think there's going to be a bit of plumbing left to do to solve bug 1725336 after bug 1238038 is done, but most of the complexity is in bug 1238038, and it shouldn't be that hard/long.

Thanks for the quick update Paul!

Just wanted to get a sense on ETA around this. A lot of work already seems to be done on bug 1238038 but just wanted to check what's ETA on that to be done now? Afterwards, how far we are with getting this bug (or bug 1725336) to be fixed?

I'm hitting this problem as well.

We are calling gUM with 'sampleRate: 48000', which currently gets ignored by Firefox because of bug 1388586. And when we connect the audio track from the mic to our AudioContext we hit error mentioned in the initial report.

Besides all of this working fine in Chrome, what makes this an annoying bug is that Firefox also doesn't report the sample rate of a track from the mic.

I guess one way to find out the sampleRate could be to connect the microphone track to an AudioContext and then look at the sampleRate. That way we could avoid hitting the above mentioned error, because we would no longer blindly connect an unknown sampleRate to an AudioContext with a fixed sampleRate.