Closed Taiko2k closed 1 year ago
So this fixes your particular issue? I suppose this change looks fine. The way I understand it, is that if PA_STREAM_FIX_RATE
is used, it gives PulseAudio the option to ignore our sample rate, but if it's excluded, it always uses our requested sample rate?
Yeah it fixes my issue. Without FIX_RATE it is then the servers responsibility to accept our given samplerate and the burden of resampling is on the server. This appears to me to be the more reliable way of ensuring the stream dosen't get needlessly resampled. It's what Pipewire guy recons miniaudio should do.
If you ask me this makes sense, the original format should be maintained as long as possible and only change formats when needed. You could imagine if the output device was changed on the server side, its better that the server does the reformatting so it can adapt appropriately.
Btw I see that ma_context_get_sink_info__pulse()
is effectively asking for the bit format from the server, but perhaps we shouldn't do that as well? Just do ss.format = ma_format_to_pulse(format)
? Idk I'm not too fussed here.
I guess this does all run contrary to your note:
- We're always using native format/channels/rate regardless of whether or not PulseAudio
supports the format directly through their own data conversion system. I'm doing this to
reduce as much variability from the PulseAudio side as possible because it's seems to be
extremely unreliable at everything it does.
But pretty much every current major Linux distro ships PipeWire by default now so perhaps those PulseAudio quirks are not such a concern now.
Thanks for this. I've finally gone and merged this.
Following on from the issue I raised about the output format with Pulseaudio, and raising the issue on Pipewire, they suggested this change where we only fix the format in the case its undefined, otherwise we pass the given format directly on to the audio server.