Before doing this (the patch is rather simple), I need to make sure this does not leak through enumerateDevice or something like this.

This might have performance implications on Android, as the audio output low-latency path only works with the primary sample-rate of the device. I'll investigate this as well.

44100 or 48000 are both the most common rate (on various OS/hw configuration), I think picking 44100 is good enough on desktop.

On mobile, sometimes 48000 instead of 44100 will bring a nice perf boost, and is super common enough to pick.

jib, would you have info about the first sentence? What does change for enumerateDevices if RFP is enabled? Can we find the system default device using one of those mediaDevices methods?

enumerateDevices already lies when privacy.resistFingerprinting is enabled (bug 1372073), returning dummy devices.

Additionally, we don't expose capabilities yet anyway through enumerateDevices (bug 1179084), so we're good there.

We don't expose sampleRate yet in track.getSettings() because we don't implement the sampleRate constraint yet bug 1388586.

I'll add notes in the open bugs to remember to respect the privacy.resistFingerprinting pref.

If the sample-rate is 44100 or 48000, use that, it's common enough (roughly
49.5% each). Else, use 48000.

https://hg.mozilla.org/mozilla-central/rev/c57ebfe0e074