Ok, folks, I’ve done the analysis, and it is a WD bug.
If you’re propeller-headed, read on. If not, suffice it to say this is a WD issue without question.
It has nothing to do with WiFi, per se, other than the fact that WiFi is much more prone to fall victim and exhibit its symptoms if you have a dodgy or under-performing network.
My testbed:
I streamed FROM a WiFi attached WD TV Live Hub a Test File provided by TechFlaws (thanks!) that demands approximately 1.9 megabits per second (average) of throughput.
General
Complete name : V:\Test\AVI Test File.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 13.6 MiB
Duration : 1mn 0s
Overall bit rate mode : Variable
Overall bit rate : 1 901 Kbps
Writing application : VirtualDubMod 1.5.4.1 (build 2178/release)
Writing library : VirtualDubMod build 2178/release
Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Custom
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 1mn 0s
Bit rate : 1 778 Kbps
Width : 720 pixels
Height : 544 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.182
Stream size : 12.7 MiB (94%)
Writing library : XviD 1.2.1 (UTC 2008-12-04)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1mn 0s
Bit rate mode : Variable
Bit rate : 109 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 797 KiB (6%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duration : 148 ms
Writing library : LAME3.98.2
The file was streamed TO a WiFi-attached WDTV Live SMP.
I streamed the file repeatedly through both Media Server (DLNA) and Network Share (Samba)
It played for over 15 minutes (on repeat mode with Samba, manual restarts with DLNA) with no loss of audio, no sync issues, no stuttering … no issues at all.
I switched from WIFI source and destination to WIRED source and destination (since it’s much easier to capture the data) and repeated the test. I dug into a network trace to see why other people are having problems, and the issue jumped right out.
Highlighted in RED are the WD’s *READ* requests from the NAS, and the NAS’s responses.
Note the lines that read:
Read AndX Request, FID xxxxx, 8 bytes at offset …
The WD is asking for ONLY 8 bytes at a time. Every now and then a larger packet will be requested (maybe 2K or so) but these are EXTRAORDINARILY small packets.
That means the overhead is HUGE.
A “normal” read request will be on the order of 60K bytes or so.
This is HORRIBLE on a WiFi network, particularly Mixed-Mode networks. The Live HUB is connected to a dedicated 5 GHz N network. No mixed mode. The SMP is connected to a G/N network. No B clients.
High-performance WLAN will be OK. Wired will be OK in the majority of cases.
But it also puts a tremendous load on the SERVER. My QNAP handles this with no issues, but some lower-end PCs or file servers will struggle to process that much network overhead without dropping packets.
… and if packets are dropped, TCP/IP (the lower-order network protocol in use here) quickly collapses due to the small packets.
So this answers the question of why ya’ll changing your “Max Transmit” rate actually improves the issue: It limits mixed-mode connectivity, and lowers the likelihood of dropped packets.
As to why this only affects AUDIO: It doesn’t. It affects the whole stream. Audio is just the first to go, because of synchronization, it will quickly go out of sync of a packet is lost and is waiting to re-establish sync. But if the problem is bad enough, the whole playback will break down.
So there ya go.
