summaryrefslogtreecommitdiff
path: root/notes/windows_network_audio.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'notes/windows_network_audio.mdwn')
-rw-r--r--notes/windows_network_audio.mdwn15
1 files changed, 7 insertions, 8 deletions
diff --git a/notes/windows_network_audio.mdwn b/notes/windows_network_audio.mdwn
index a206afe..ba34cf4 100644
--- a/notes/windows_network_audio.mdwn
+++ b/notes/windows_network_audio.mdwn
@@ -58,17 +58,16 @@ 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][1] settings in order to avoid
introducing resampling latency.
-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.
+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.
[1]: http://software.muzychenko.net/eng/vac.htm
[2]: http://sox.sourceforge.net/