View RSS Feed


Network Resource Requirements/Testing & Observations of Streamed Music Files Located On A NAS Device

Rate this Entry

This blog post will be a work in progress as time and motivation allow but in this first go round I wanted to start off by talking about the bandwidth requirements (As Observed) from a networking perspective while streaming several different flavors of music files found in your average Audiophiles music library.

To date, I have not yet seen anyone post this sort of information on the web showing the actual "flow" patterns and behavior of the various streamed files under test. Understandably, this is probably not all that interesting to many folks and maybe even a bit too far "in weeds" for this given topic but in any event I found it quite interesting and felt maybe the information could be useful to the Computer Audio community in some way now or in the future.

At this point its probably a good idea for me to first talk about how I went about gathering this sort of information to prove its validity and worthiness of posting. Afterwards I will move on to the meat and potatoes of the topic itself.

Preparation Steps:

Step 1

I built a dedicated NMS (Network Monitoring Station) using a fresh install of Windows 8.1. The NMS itself is a virtual machine which lives as an instance on Oracle's Virtual Box platform. The physical host machine which supports the virtual NMS runs a copy of Ubuntu 14.04 LTS.

During the install of the NMS I chose to place its virtual disk files on the local Ubuntu Host as to avoid any unnecessary network activity which could have skewed the results gathered during this test. The virtual NMS had its network card configured as a "Bridged" adapter which essentially means that it is a dedicated resource on the network, has its own unique MAC Address and receives a DHCP IP Address all its own. This step should, I believe, help filter out any excess chatter taking place on the physical Unbuntu host itself where the virtual machine resides.

Step 2

Once my NMS was built I proceeded to download a copy of Paessler's "PRTG Network Monitor" software which I have used in the past while doing my day job and am very familiar with. The software is Free for 30 Days and includes full functionality during that time. I then performed the install on the fresh Win 8.1 NMS virtual machine.

Step 3

I used an enterprise class 8-Port Cisco 2960G switch between the NAS being tested and the NMS computer. The switch itself is a bit more advanced then your average Linksys but still only a basic Layer2 device ( routing). Despite being a lower end Cisco product it still includes the ability to configure an SNMP (Simple Network Management Protocol) community which is the protocol I ultimately used gathered the data for this blog post. Another benefit of using this switch is that it includes a fairly sizable and mature library of MIB's (Management Information Base) for use with SNMP for monitoring purposes.

Step 4

After setting up an SNMP community on my Cisco switch I then used the PRTG software to scan the IP Address of the switch to look for sensors to monitor. One of the sensors it discovered was the Ethernet Interface where my Synology NAS is plugged into. This interface and the network traffic passed thru it is the source for all data gathered for this blog post.

Once I had the above configured I proceeded to adjust the default data gathering interval used by PRTG (60sec) to something a bit more aggressive. In this case I used the lowest supported interval of 10sec per sample. Basically this means that every 10 sec the PRTG monitoring software will "Sniff" the port where the NAS device is plugged into and show me what it see's on a graph and table within the PRTG software. In my case, I will use the Table data from PRTG to then Import it into an MS Excel Spreadsheet for chart creation as seen later in this post.

The Streamed Music Files Being Tested:

So in order to maintain some form of consistency for this test I dug thru my music library for a group of files that all used the same file type. In the case of this test I used all .FLAC files (except DSD) at the following Bit/Freq rates:

16bit x 44Khz - Paul Van Dyk - The Other Side - Politics of Dancing Album
24bit x 48Khz - Peter Gabrial - Heroes - Scratch My Back Album
24bit x 88Khz - Three O'Clock Blues - Eric Clapton & BB King -Riding w/ the King Album
24bit x 96Khz - Stevie Ray Vaghn & Albert King - Blues At Sunrise - In Session Album
24bit x 192Khz - Madonna - Lucky Star - Madonna Album
DSD64 (.dsf) - Boston - More Than A Feeling - Boston Album

The Test Process

The test approach was pretty simple. I would play each file one by one, record its start and end time, copy the data in the PRTG table for that file then move on to the next one. Rinse and Repeat. Doing it this way would also help to keep the information in the table within the PRTG software nice and separate to avoid any mistakes.

The PRTG Software was able to gather both the Volume of data coming from the NAS to the Cisco switch as well as the Speed/Rate at which that data was passing thru the Interface. The Interface used by my NAS is marked ETH0/3. I choose to use this Interface as my data gathering source because there are no network hopes involved between it and the NMS virtual machine which is Local to the same switch. Maybe at some point I will try another test on a different switch further downstream which is Local to the music server itself and see if the output on the chart looks any different then it does here.

The Results

As you will see below the different files do exhibit a very different behavior as they pass thru the switch. The Red Book file appears to require very small, short bursts of network bandwidth while playing. You can see that roughly every 30 secs or so the music server asks for a 4MB burst and in between that request there are other smaller requests for 1KB of data every 10sec. I suspect this has something to do with pre-determined buffer sizes configured on the music server for the various files being tested.

I found it very interesting that the 24x192 file was the most demanding in all cases. This went against my initial assumption that the DSD file would be the most demanding since I thought it contained more data. After some further thought on this I suspect it has something to do with how the file is packaged. Maybe more efficient with less white space but thats just a hunch.

Nevertheless, in the grand scheme of things there doesn't look to be any real issue present in terms of the streaming bandwidth requirements for any of the files as long as someone can ensure a solid 30MB of bandwidth is available for streaming from a wired or wireless connection at home. One thing that folks should take notice to though is that during the beginning of each song there is a fairly large spike/request made to begin playback for each of the files and as the file quality goes up so does the need to maintain that solid 30MB of readily available bandwidth. For those in the Wireless camp with antennas at further distances away it wouldn't be hard to imagine that some parts of the house may not have 30MB of headroom to play with so check to make sure your covered (no pun intended) to avoid any issues.

Well thats all I have for now. Please feel free to offer any thoughts or observations of your own


Traffic Analysis - Incoming Transfer Rate Comparison of the various files under test


Traffic Analysis - Incoming Data Volume Comparison of the various files under test



  1. The Computer Audiophile's Avatar
    Thanks for such a detailed post. This is very cool!
  2. cjf's Avatar
    Sure thing. I appreciate you taking the time check it out.
  3. SeeHear's Avatar
    Can you configure your player to play from memory and show the results? This is really interesting data - it is good info to know when planning to serve multiple renderers/clients from one server.

    Thanks for running this test.
  4. cjf's Avatar
    Hello and thanks for taking a look at my blog post. My music server is one that already does everything from memory in terms of streaming so the results posted reflect that configuration.

    I use Voyage Linux MPD which has a Read Only operating system. Upon boot up, it loads the whole OS and any needed processes in RAM (256mb). The MPD process is run via the Real Time Kernal and is given high priority in the resource pecking order.

    You bring up a good point though about memory play that I should have probably talked more about in my original post. I guess depending on how one has their music server or App configured it's certainly possible to have different results. For example, if someone configures the streaming App to buffer the entire song into RAM before playback then I suspect we would see a very large, long duration stream of data on the graph before playback begins then probably just small handshake communication after that for the remainder of the song playback.

    For my configuration I have the MPD process set to buffer 4MB of streamed data into RAM and it is then set to wait until 10% of that 4MB buffer is filled before any playback of music will start.

    These values are certainly configurable and in my case I bumped up the buffer from default 2MB to the present 4MB setting. There is a trade off though the greater you increase the buffer size and that trade off is hearing a "Pause" in playback between songs while the buffer fills so gape less playback can become an issue if one gets to ham fisted with the buffer settings.

    Ultimatly I believe the packet size is already predetermined either by the DAC USB receiver chip or within the streamer App/Program depending on the sample / bit rate of the song being played. Because of this, there is a point of diminishing returns on the amount one decides to buffer ahead of time.

    I may toy around with making the buffer very large just to see the outcome on the graph. If I do, I'll post up the results.