For what it's worth, I did some more tests to try and characterise the data throughput under different scenarios. I compared WAV, FLAC and 'preset insane' MP3 (all created from the same original FLAC file), using both wired and wireless connections. For reference, this is with an unmodified Touch and with SBS 7.5.3 running on a Mac Mini.
For the wired connection, I found that the WAV file starts with a burst of data transmission at ~1.7 MB/sec, then settles to a nominal rate of about 180-210 KB/sec. With only a single track queued, data transmission drops off to (almost) nothing 27 seconds from the end of the track and stays there till the end. I say 'almost' nothing, because there seems to be a continuous base level of ~23KB/sec, which is the same even when the player is powered down. For the FLAC file, the initial burst reaches ~1.2 MB/sec, and the nominal playing rate is between 100 and 150 KB/sec. Data transmission stops at 45 seconds from the end of the track. For the MP3 file, the initial burst is ~1.1 MB/sec, the nominal playing rate is 60-70 KB/sec, and the drop off happens a full 1m30s from the end of the track. For the wireless connection the characteristics are all the same, except that the initial burst seems to be slightly slower, with a maximum of about 1 MB/sec. So what can we conclude? It certainly looks as though all 'music' data comms stop some time before the end of the track, regardless of whether the connection is wired or wireless. So for assessing the impact of network comms, this does look like a good area to concentrate on. I know that some will argue that the processor is still doing something with the connection, even if no music data is being sent, but the level of transmission during this period is the same as when the player is off, and is common to both wired and wireless connections. For WAV transmissions, the end of music transmission seems to happen almost 30s from the end of the track, so it gives us a useful length of time to listen for improvements in the sound. For FLAC we get about 50% more time at the end of the track, and for 'insame' MP3s we get 3 times as long - half the length of the typical 3-minute track. Obviously I expect most self-respecting audiophiles to tell me that even 'insane' MP3s sound lousy, and their flaws will drown any effects due to network comms. I suppose the same argument will be levelled against FLAC files, so the penalty for sending WAVs (~200KB/sec versus ~125KB/sec for FLAC) is compensated by not overloading the processor with FLAC decoding duties. Anyway, do what you like with this information. It might be useful to see if similar tests are possible with Windows and Linux environments. The process I was monitoring on my Mac was called perl5.10.0, and it would make sense to expect that the perl code is common to all platforms, so the gross characteristics of the data transmission might be common. But who knows. -- chill ------------------------------------------------------------------------ chill's Profile: http://forums.slimdevices.com/member.php?userid=10839 View this thread: http://forums.slimdevices.com/showthread.php?t=84742 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
