From df4757a073eb44a4932f736ac57e69b56228b9a0 Mon Sep 17 00:00:00 2001 From: Joe Rayhawk Date: Wed, 27 Jul 2011 18:40:51 -0700 Subject: Notes: windows network audio: reformating additional notes to combine topics better --- notes/windows_network_audio.mdwn | 15 +++++++-------- 1 file 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/ -- cgit v1.2.3