Notes: Windows network audio: new

1 files changed, 72 insertions, 0 deletions

diff --git a/notes/windows_network_audio.mdwn b/notes/windows_network_audio.mdwn
new file mode 100644
index 0000000..936d2aa
--- /dev/null
+++ b/notes/windows_network_audio.mdwn
@@ -0,0 +1,72 @@
+# Windows Network Audio
+
+Prerequisites:
+
+* [Virtual Audio Cable][1]
+* [Some Windows compile of SoX][2]
+* [Some Windows compile of netcat][3]
+
+
+
+## Getting a PCM UDP stream *out of* a Windows virtual audio device:
+
+In [VAC][1], 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
+
+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][2]
+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 192.168.0.103 8001
+
+
+
+## Additional notes
+
+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][4]'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.
+
+Windows sometimes does something horrible to TCP buffering; if you value
+latency, use UDP wherever practical.
+
+To make your life easier you might want to wrap the listening netcats in
+`while sleep 1; do ; done`
+
+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. OTOH, dropped UDP packets do not seem to
+cause any framing/alignment problems.
+
+  [1]: http://software.muzychenko.net/eng/vac.htm
+  [2]: http://sox.sourceforge.net/
+  [3]: http://www.rodneybeede.com/Compile_Netcat_on_Windows_using_MinGW.html
+  [4]: http://sox.sourceforge.net/soxformat.html