When connecting to a remote machine via Citrix, the devices on the remote machine exposes a very small buffer size. This is too low for (e.g.) doing a WebRTC call with a robust audio input stream in Firefox. It's in fact not that much of a problem to increase the buffer size between audiodg.exe and cubeb, and makes the input a lot better. The buffer size itself doesn't affect latency that much, it's apparently something like a ring buffer that a bit bigger, so more robust on various under-runs, but latency is still kept quite low. I've tested this on the Citrix setup (where it improves the quality greatly), and on a couple local setups (where it seem to add a few milliseconds of latency maybe, but I'm not sure).
Also, cubeb_wasapi.cpp is currently grabbing the input data from the output event. This has been working well for years, but doesn't work too well on Citrix that has minuscule buffer sizes: if the output event is each 10ms, and the input event is around 133 frames at 48k (typical values for the Citrix setup I've tested this on), we end up missing a lot of input because it doesn't appear to be buffered for long enough. I think that as a followup up, to further increase robustness against load, for when the output's callback load is very high, we might want to spin a thread just for input. I have half the patch written for this.
Additionally, this adds logging to quickly check if a setup is under-running, or if the input if drifting vs. the output, and fixes some weirdness in wasapi_get_min_latency that would return the number to use with IAudioClient3, but this path has been disabled for now.
This also increases quality of the input with my Sony WH1000-XM3 (locally), it was suffering with more or less the same symptomes: input buffer size too small, device period too small.
When connecting to a remote machine via Citrix, the devices on the remote machine exposes a very small buffer size. This is too low for (e.g.) doing a WebRTC call with a robust audio input stream in Firefox. It's in fact not that much of a problem to increase the buffer size between
audiodg.exeand cubeb, and makes the input a lot better. The buffer size itself doesn't affect latency that much, it's apparently something like a ring buffer that a bit bigger, so more robust on various under-runs, but latency is still kept quite low. I've tested this on the Citrix setup (where it improves the quality greatly), and on a couple local setups (where it seem to add a few milliseconds of latency maybe, but I'm not sure).Also,
cubeb_wasapi.cppis currently grabbing the input data from the output event. This has been working well for years, but doesn't work too well on Citrix that has minuscule buffer sizes: if the output event is each 10ms, and the input event is around 133 frames at 48k (typical values for the Citrix setup I've tested this on), we end up missing a lot of input because it doesn't appear to be buffered for long enough. I think that as a followup up, to further increase robustness against load, for when the output's callback load is very high, we might want to spin a thread just for input. I have half the patch written for this.Additionally, this adds logging to quickly check if a setup is under-running, or if the input if drifting vs. the output, and fixes some weirdness in
wasapi_get_min_latencythat would return the number to use withIAudioClient3, but this path has been disabled for now.This also increases quality of the input with my Sony WH1000-XM3 (locally), it was suffering with more or less the same symptomes: input buffer size too small, device period too small.