Don't specify sample rates for voice messages

[turt2live]

Turns out the browser doesn't actually resample for us, instead opting to explode in sadness.

We'll leave the resampling to the opus encoder.

Fixes element-hq/element-web#16775

[dbkr]

Hmm, presumably you haven't been able to test this? This would have just been specifying an ideal sample rate, so if the capture device didn't support that the browser will give you whatever's available. If you want to force it to resample I think you'd have to add an exact requirement.

From the rageshake, it looks like it's failing to connect the two nodes of different sample rates, so by not specifying a sample rate I'd have thought you'd still get whatever the capture device is spitting out, so you'd get the same error?

One solution might be to have the ideal constraint but then inspect the sample rate you actually get and init the audioContext with that.

That said, if this does work then fine :)

[turt2live]

I indeed don't have a way of testing this: my audio stack is capable of producing all the suggested sample rates.

Ultimately, it's the same CPU to resample in the browser or in the encoder (practically), so I'm not too concerned about it. If we start getting complaints about high CPU usage then let's figure something out.

[turt2live]

@dbkr can I get a checkmark so github isn't mad at me? 😇

[dbkr]

Can certainly try it, but to be clear my concern isn't CPU usage, it's that it won't fix the error.

[turt2live]

oh, well, hmm. It should fix it because the sample rate goes through implicitly.

[turt2live]

... at least that's how I'm understanding the docs this time around.