How to optimize audio transmission?

[kosuodhmwa]

hi there

setup

• transmitter: Win10 x64 Professionl, WLAN, UltraGrid version 1.9,9
• receiver: Win10 x64 Professional, LAN, UltraGrid version 1.9,9

It works not bad, but sometimes, there are some buffer problems so it seems, which causes some scratchy noises.

Command i use on transmitter (batch file):
cmd /k uv -s portaudio:17 -m 1200 --audio-codec OPUS:bitrate=96000 192.168.2.243

Command i use on receiver (also batch file):
cmd /k uv -r portaudio -m 1200 --audio-codec OPUS:bitrate=96000

("Device 17" is a virtual audio device on transmitter, so i don't hear anything, so i also don't need to mute anything, with "Virtual Audio Cable 4.70 used as an WSAPI output device...)

Are there some possibilities to optimize it? So i saw, there are more options on Linux than on Windows.

Maybe it's possible to change some buffer settings, but i did not find anything compatible with my setup.

Thank you very much for your feedback(s)

With best regards

[kosuodhmwa]

i think 48000 is the default sampling rate?

How to change it to 44100? The soundcard on receiver does not support 48k, so it does not make sense i.m.o...

(But i dont think that solves my issue, but anyway... my issue is more a problem of too small buffer or something like that)

[MartinPulec]

Are there some possibilities to optimize it? So i saw, there are more options on Linux than on Windows.

Hi, definitely - but I don't know what is the problem - can you paste the output from the receiver, at least something like a minute long? I'd like to see if there are losses/overruns/underruns or so.

Maybe it's possible to change some buffer settings, but i did not find anything compatible with my setup.

You can try --param audio-buffer-len=100 on the receiver (it is in milliseconds). You can also try to use wasapi instead of portaudio. This could work better (but also the opposite is possible). It is the Win native driver - PA has the WASAPI backend as well. Also for PortAudio - you can try use another backend than you use for the particular device (can be seen in :help).

[MartinPulec]

i think 48000 is the default sampling rate?

well, usually so but not always - eg. when the device doesn't support that, some supported is used if possible

How to change it to 44100?

On the sender, you can explicitly request -a sample_rate=44100.

It affects the sender only - on the receiver, if the device doesn't support received sampling rate, the resampling takes place to coalesce to a supported format. This can be seen in the output of the receiver:

New incoming audio format detected: 48000 Hz, 1 channel, 16 bits per sample, codec PCM
Audio reconfiguration succeeded (1 channel, 2 Bps, 48000 Hz, codec: PCM).

Here, in this output, the received properties and configured match. But if the playback device supported just 44.1 kHz, on the second line would be 44100.

[kosuodhmwa]

Thank you very much for your feedback.

Hmmmm this sample rate parameter does not work so it seems, maybe it's a specific problem on my plattform?

**
C:\Tools\Audio\UltraGrid>cmd /k uv -s portaudio:17 -a sample_rate=44100 -m 1200 --audio-codec OPUS:bitrate=96000 192.168.2.243
[host] Running inside PS/cmd terminal is not recommended because scrolling the output freezes the process, consider using Windows Terminal instead!
UltraGrid 1.9.9 (tags/v1.9.9 rev 8035b2f built Mar 21 2025 14:09:03)

Display device : none
Capture device : none
Audio capture : portaudio:17
Audio playback : none
MTU : 1200 B
Video compression: none
Audio codec : Opus
Network protocol : UltraGrid RTP
Audio FEC : none
Video FEC : none

[PortAudio] Using PortAudio V19.7.0-devel, revision 147dd722548358763a8b649b3e4b41dfffbcfbb6
Initializing portaudio capture.
Using PortAudio version: PortAudio V19.7.0-devel, revision 147dd722548358763a8b649b3e4b41dfffbcfbb6
[Portaudio capture] Using input audio device: Line 1 (Virtual Audio Cable)
[Portaudio capture] Error opening audio stream
PortAudio error: Invalid sample rate
Error initializing audio capture.
Exit

C:\Tools\Audio\UltraGrid>
**

[kosuodhmwa]

Correct syntax for OPUS seems to be that:

cmd /k uv -s portaudio:17 -m 1200 --audio-codec OPUS:bitrate=96000:sample_rate=44100 192.168.2.243

Yes, it's not supported. But not a real problem, because the problems are not transfer rate, but latency to i think:

[kosuodhmwa]

the adding of '--param audio-buffer-len=100' on RECEIVER seems, at least on syntax, wo work on the receiver. Will test it now. Thx again, :-)

[kosuodhmwa]

Regarding the playback device: What i have done is this then i selected the virtual audio device (so it's muted in every case on sender) in the WSAPI implementation (most modern i think)

[kosuodhmwa]

The parameter '--param audio-buffer-len' has changed it so it seems... but it needs to be much higher than 100ms... also with 500ms there are some (short) scratchy noises sometime. Now i changed it to 1000ms and the problem seems to be gone (at least until now).

But, to be honest, i do not really wonder it needs that very high value with my GL-MT300N-V2 (with OpenWRT 24.x) they support 802.11b/g/n without antenna HAHA... ;-)

[MartinPulec]

Hmmmm this sample rate parameter does not work so it seems, maybe it's a specific problem on my plattform?
...
PortAudio error: Invalid sample rate

It seems rather that the parameter itself works, but the input device doesn't support 44.1 kHz. But from the further, it doesn't seem to be the issue, anyways.

Now i changed it to 1000ms and the problem seems to be gone (at least until now). ... But, to be honest, i do not really wonder it needs that very high value with my GL-MT300N-V2 (with OpenWRT 24.x) they support 802.11b/g/n without antenna HAHA... ;-)

Yes, the value is very high, indeed. It doesn't seem to me that it is just because the wifi itself, maybe if you use VPN? The buffer you are setting the value with the param is dummy - if such that value is needed, it AFAIK mean that there is high time jitter from the sender to the receiver.

[kosuodhmwa]

Thank you for your feedback.

- oh, then its just a random thing? Or is it a dummy if the value is TOO high? (so the same result as not set / without that parameter)

Currently, the batch file on receiver has this commands (the first without that parameter is currently just a comment - testing purposes):

rem cmd /k uv -r portaudio -m 1200 --audio-codec OPUS:bitrate=96000
cmd /k uv -r portaudio -m 1200 --audio-codec OPUS:bitrate=96000 --param audio-buffer-len=2500

Yes, i use a VPN connection for internet, that is the default gateway when connected (will do routing). But i also have access to my local subnet 192.168.2.0/24 (will do NO routing if VPN is connected, e.g. i have no access/routing to the other 5G mobile internet router [daisy chain] 192.168.254.3 - but access to all other hosts on 192.168.2.0/24...)

[kosuodhmwa]

or is there a maximum value which will be uses if audio-buffer-len=... is too high?

[MartinPulec]

Or is it a dummy if the value is TOO high?

It isn't. But of course it can influence latency - if it is set to 1 second, it doesn't automatically mean that the latency will be increased by that 1 second but in case that it is the lowest value to work flawlessly, I'd guess that it is so.

As for the VPN - yeah, that seem to explain that. If you use TCP VPN and there are some network losses, the eventual retransmissions delay the packets and thus hurt the timing. If the added latency is not problem for you, it is OK; otherwise you may consider VPN over UDP.

or is there a maximum value which will be uses if audio-buffer-len=... is too high?

I think that you can use any value if you are OK with the added latency.

[kosuodhmwa]

thank you very very much for your answer! :-)