Streaming audio output from Linux (Pulseaudio) to Windows

gistfile1.txt

# Windows (receiver) side:
.\ffplay.exe -nodisp -ac 2 -acodec pcm_u8 -ar 48000 -analyzeduration 0 -probesize 32 -f u8 -i udp://0.0.0.0:18181?listen=1

# Linux (transmitter) side:
pactl load-module module-null-sink sink_name=remote
ffmpeg -f pulse -i "remote.monitor" -ac 2 -acodec pcm_u8 -ar 48000 -f u8 "udp://RECEIVER:18181"
pavucontrol # Change the default output to the Null sink or move single applications to this "output" device.

What IP Address should I put for the receiver? How can I discover it?

The MS Windows receiver is listening on all interfaces (I believe on ipv4 only, but I haven't looked further). On windows you can find out the IP addresses by typing ipconfig within the windows terminal.

The Linux client is the one that sends to the address of the MS Windows computer.

I am trying to get this to work sending sound from a raspberry pi to Windows 10. I have it such that There was popping on the windows machine but no intelligable sound. Is there something I need to do with the sound input on the pi or output on windows 10? Below are the commands I used except that for windows I ran the program in the folder with ffplay so did not use './'

Windows (receiver) side:

.\ffplay -nodisp -ac 2 -acodec pcm_s16le -ar 48000 -analyzeduration 0 -probesize 32 -f s16le -i udp://0.0.0.0:18181?listen=1

Linux (transmitter) side:

pactl load-module module-null-sink sink_name=remote
ffmpeg -f pulse -i "remote.monitor" -ac 2 -acodec pcm_s16le -ar 48000 -f s16le "udp://<RECEIVER'S IP ADDRESS>:18181"

i have a massive lag with this, and the 2 computers are connected per cable, what can i do to make it better?

If you have plenty of bandwidth (in other words if you can spare 3mB/s), replacing all the u8's with u32les really improves the sound quality

There are probably more efficient ways to encode it but I'm not an expert

This works for me perfectly on Lan, with 0 latency i believe.
I'm uploading the code here so i won't lost this code.. if this works well for anyone else, its a good news!

Linux (transmitter) side:
pactl load-module module-null-sink sink_name=remote
ffmpeg -f pulse -i "remote.monitor" -ac 2 -acodec pcm_s16le -ar 48000 -f s16le "udp://<RECEIVER'S IP ADDRESS>:18181"

Windows (receiver) side:
.\ffplay -nodisp -fflags nobuffer -flags low_delay -strict experimental -fflags discardcorrupt -ac 2 -acodec pcm_s16le -ar 48000 -analyzeduration 0 -probesize 32 -f s16le -i udp://0.0.0.0:18181?listen=1

(try running windows command later)

This works for me perfectly on Lan, with 0 latency i believe. I'm uploading the code here so i won't lost this code.. if this works well for anyone else, its a good news!

Linux (transmitter) side: pactl load-module module-null-sink sink_name=remote ffmpeg -f pulse -i "remote.monitor" -ac 2 -acodec pcm_s16le -ar 48000 -f s16le "udp://<RECEIVER'S IP ADDRESS>:18181"

Windows (receiver) side: .\ffplay -nodisp -fflags nobuffer -flags low_delay -strict experimental -fflags discardcorrupt -ac 2 -acodec pcm_s16le -ar 48000 -analyzeduration 0 -probesize 32 -f s16le -i udp://0.0.0.0:18181?listen=1

(try running windows command later)

Im getting 3 second on this one. Are you using a spesial version of something? ( Im on ubuntu to windows)

You can try adding -flush_packets 1, -fflags discardcorrupt, -fflags nobuffer, -flags low_delay, -muxdelay 0.01 on the output section of the transmitter side, that might cut down on some latency too but I haven't tried any of the options to see if they're compatible with the stuff I posted.

@Fusl hey. just checked the flags, there is some delay even after using them.
is there any way we can force the speed to 1x, currently terminal of the transmiter shows me this.
"size= 17972kB time=00:01:35.84 bitrate=1536.1kbits/s speed=1.04x"
which I think that 1.04x speed is giving me the latency.

Also for some reason, I had zorin os installed, i ran the previous script I mentioned, and it gave me 0 lag. even after using it for a week.
Then i install vanilla arch and used the script on the transmitter side, on arch the 3 sec lag comes.
my question is is there any additional packages installed by default on zorin os which supports ffmpeg from behind? or debian provides better support for ffmpeg than arch?

so did anyone find a fix for latency? (1 sec on Linux Lite -> win 11)

Nope

so did anyone find a fix for latency? (1 sec on Linux Lite -> win 11)

Yes. I haven't used Windows for over a year, so this was with Windows 10. It involved ditching ffmpeg piping, and using an old version of PulseAudio that was ported to Windows ages ago. Once both systems (Linux, Windows, or whatever) are using PulseAudio as a platform for sound, then you can network the PulseAudio way, which is very low latency. You can watch movies over the network with no noticeable delay.

Here is the post that got me started. I can't remember if I used version 1.1 or 5 that they mention.

https://www.reddit.com/r/bashonubuntuonwindows/comments/hrn1lz/wsl_sound_through_pulseaudio_solved/

Couple of things:

• make sure the user on both machines have the same cookie file (often here on Linux ~/.config/pulse/cookie), so copy this over to where your PulseAudio config is on Windows. On Windows it didn't seem to store anything in your home folder, everything was just in the one folder.
• on the receiving machine put this in the equivalent of /etc/pulse/client.pa: default-server = 192.168.7.3
• on the transmitting machine put this in the equivalent of /etc/pulse/default.pa:

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;<insert IPs of machines>

The IPs would be listed like 192.168.0.1;192.168.0.2 or CIDR notation like 192.168.0.0/24 to specify a range.