Home > TEST, USB AUDIO > Bulk Transfer Mode in Musiland Monitor Devices

Bulk Transfer Mode in Musiland Monitor Devices

February 5, 2011 Leave a comment Go to comments

After some reports at head-fi indicating that the Musiland device driver uses bulk mode transfer, I decided to do some USB port snooping of my own by downloading one of the many USB protocol analyzers tools available in the internet. I decided to try USBlyzer BETA (no real reason, other tools should be just as good) to capture the data through the Musiland device while playing a music track.

This is what I found:

  • Transfer mode is indeed bulk transfer.
  • The size of the packet varies with the sample frequency. For 44.1K material, the size is 2KB and for 96K material, it is 4KB. I also tested 176.4K material and the packet size is 8KB (8,192 bytes).
  • Bulk data transfers happens about every 5 msec. If you do the math, the size of the transfer at this rate is about 2x the data required to support the music sample rate (24bits x 2 channels x sample rate). I suppose this “headroom”  is to prevent loosing data due to things like transfer retries, bandwidth sharing, etc. And of course the device only transfers enough data to keep a constant data transfer to the DAC. In contrast, Isochronous transfers in a fixed 1-msec interval
  • There is a ~20 msec latency between the request and delivery of data, but there is a request every 5 msec.
  • From the trace, we can see a “success” status. This I think reflects the guaranteed data delivery feature of bulk transfer (the endpoint has received the data with no error)

The following images show the captured data flow through the Musiland device while playing a 24/96KHz track. In order to understand the data we can reference the following explanation:

OUT: When the host wants to send the function a bulk data packet, it issues an OUT token followed by a data packet containing the bulk data. If any part of the OUT token or data packet is corrupt then the function ignores the packet. If the function’s endpoint buffer was empty and it has clocked the data into the endpoint buffer it issues an ACK informing the host it has successfully received the data. If the endpoint buffer is not empty due to processing a previous packet, then the function returns an NAK. However if the endpoint has had an error and it’s halt bit has been set, it returns a STALL.

Some observations:

  • Since bulk transfer protocol ensures data integrity and there is ample headroom, timely and accurate data delivery is virtually guaranteed
  • Based on the above observation, the Musiland device should be insensitive to USB cable length and other “issues”
  • Transfer rate is about 5X less than Isochronous transfer which requires a transfer every 1 msec. This means that a PC needs to service a transfer every 1 msec for a Isochronous device and “only” once every 5 msec for the Musiland device. Thus the Musiland device is less sensitive to how busy the microprocessor is doing other things
  • It is still a good idea to use a usb port that is not shared with other devices; however, with ample headroom, this doesn’t seem to be that critical

Conclusion

It appears the Musiland device is the only “hifi” consumer USB device that uses bulk mode transfer. Other notable devices including the highly acclaimed M2Tech use Isochronous-asynchronous transfer mode. The advantage of bulk transfer over Isochronous-asynchronous transter is the guaranteed nature of the data delivery. The advantage of Isochronous transfer over bulk is the guaranteed bandwidth; however if there is plenty of bandwidth available (for example, you are not maxing out the bandwidth of the USB connection by plugging in several devices), then guaranteed bandwidth is never an issue.

Musiland has designed an audio class device driver that is robust, accurate and with guaranteed data delivery. The fact that this makes it insensitive to “whatever’ happens in the PC is perhaps a reflection of Musiland’s primary market where people’s preferences and living conditions would likely preclude having a PC dedicated for music alone. My own experience reflects that reality. I have often marveled at the fact that the music “never skips a beat” no matter what I do in the PC.

Update: 7/5/11

Here is “proof” that the bulk transfer mode works well: [link]

A test was performed to evaluate data integrity of the Musiland 01USD. The test consisted in playing a 24/192k file, captured digitally (through the SPDIF interface) with another sound card and then making a comparison between the original file and the captured file.

Simmconn downloaded a 24/192K file in flac format and converted it to WAV 24/192 (almost 600MB, the size of a typical CD), played it with foobar and output the digital signal through a Musiland 01USD. The digital signal was then captured through an M-audio Audiophile sound card and Adobe’s Audition software.  The source and destination files were aligned and then compared bit by bit with an HEX editor. The result: exact match.

  1. Florin
    February 6, 2011 at 19:17

    Hello,

    Nice finding, for some reason (probably some info from diyaudio) I’ve always thought that the musiland was isochronous, and I tended to ignore it, despite the excellent price. There’s no reason for me for not buying it now..

    Now only if musiland would make an effort and release a multichannel version..

    Great site, by the way, truly excellent stuff here!

  2. BlogGeanDo
    February 7, 2011 at 00:30

    Hello Florin, thanks!
    It is good to see a company put together an advanced driver with a rock-bottom priced device. Now I wish they would improve the clock generation part by using local clocks rather than using the DCM in the FPGAs to derive the clocks.

  3. September 14, 2016 at 18:16

    submit job

  1. May 12, 2011 at 22:53
  2. October 3, 2012 at 16:21
  3. April 23, 2013 at 01:23

Leave a comment