Windows Network Audio

Prerequisites:

• Virtual Audio Cable
• Some Windows compile of SoX
• Some Windows compile of netcat

Getting a PCM UDP stream out of a Windows virtual audio device:

In VAC, make cable 1, then make it the default audio device in mmsys.cpl.

On the receiving host, run something to the effect of

nc -n -u -vvv -l -p $receiveport | aplay --buffer-size=1024

Though obviously we're not too picky. Anything that can understand a wave header will do. aplay is simplest in my case. Normal Linux desktop or N900 users might want to use pacat instead of aplay.

On the sending (Windows) host, run something to the effect of

sox --buffer=1024 -t waveaudio 1 -t wav - | nc -u $receivehost $receiveport

Getting a PCM UDP stream into a Windows virtual audio device:

If you want a separate (non-echoing) device for a microphone, make VAC cable 2, then make it the default communications device in mmsys.cpl.

On the receiving (Windows) host, run something to the effect of

nc -n -u -vvv -L -p $sendport | sox --buffer=2048 -t wav - -t waveaudio 1

On the sending host, run something to the effect of

arecord --buffer-size=2048 --verbose -f cd - | nc -u $sendhost $sendport

Additional notes

After three hours, static (from Windows) or silence (to Windows) arises instead of the PCM stream expected. I assume this is due to some addressing limit in 32-bit SoX. A 64-bit version should probably be tested.

This was done on Windows 7. The core concepts should work fine on other versions, though the details of making separate device defaults for playback and recording will presumably be different.

The SoX documentation's claim that -t waveaudio can match device names did not pan out for me, so I had to work out their index number by hand. They start from 0. In my case, it's 1.

Restarting any part of this sox/netcat/netcat/alsa chain requires restarting everything in order, since that wave header is critical. You can probably make the network half of this a bit more dynamic by manually specifying a raw PCM format on both ends rather than relying on the wave header, but you'd have to be careful to match the VAC settings in order to avoid introducing resampling latency.

To make your life easier you might want to wrap the listening netcats in while sleep 1; do ; done

Windows sometimes does something horrible to TCP buffering; if you value latency, use UDP wherever practical. Raw PCM over UDP obviously has some concerns; in heavy traffic it does not compete for bandwidth the way TCP does, does not degrade to lower quality, and is difficult to secure. You can use traffic shaping, encoding to voice codec, and/or DTLS to solve these problems. On the plus side, dropped UDP packets do not seem to cause any sample framing/alignment problems.