The idea for High Resolution Technologies and the Music Streamer line came about when Michael came back from a trip to Europe last summer and mentioned to me a USB-connected DAC he saw in Switzerland. We spoke about it and I offered that there were things that could be done to improve upon what he had heard. Eight weeks later we introduced our first two products—The Music Streamer and The Music Streamer+ at the Consumer Electronics Show.
SS: What did you find when you examined USB DACs?
KH: Generally, they all missed several important factors (at least in my opinion) when considering any computer-sourced listening. Specifically, they did little, if anything to address the inevitable contamination that can result from the common connection between the computer and the audio system. Most designs that I looked at also improperly handled their power supplies and analog output stages for this type of application.
SS: What did you do differently in the Music Streamer?
KH: A few things really. Some of the differences include a topology that provides complete isolation between the computer side and the audio side, a unique HF power supply for the USB transceiver and audio sides, and unique jitter suppression.
SS: What differentiates the Music Streamer from the Music Streamer+?
KH: Besides the obvious price difference, the important difference is their performance. There is a considerable difference in the converter topology, reconstruction filters, and output buffer of these two products.
SS: Do you see them for different markets or users?
KH: The price differentials and our expectations of sales volume are vastly different for these two models. The Music Streamer should be considered a moderate-priced product for the average consumer; in the hi-fi world it might be considered absurdly inexpensive. One of the goals was to develop a product that could sell to a wider portion of the population; the Music Streamer directly targets these individuals. The Music Streamer+ is intended for more seasoned audiophiles and for those that have systems that justify and allow for the appreciation of the performance differences.
SS: Why did you choose 2.25V output for both?
KH: Nearly all USB-powered devices suffer from inadequate output magnitude, which typically results from the limitations of the USB-bus power-supply level. The output magnitude that I chose is fractionally above that of a typical AC-powered source components like a CD player. There are advantages in the resulting signal-to-noise ratio that this higher level provides.
SS: What is your position on asynchronous versus synchronous modes over USB?
KH: The answer to your question requires more than a simple answer as it presumes that there are only two choices. Without giving away too much, let me expand on this just a bit (no pun intended).
First, a synchronous data transfer can be accomplished in more than one way. By definition, it means that the data rates of the host and client are linked to the same clocking scheme. The simplest is where the host (most often the computer end) provides the clock and the client (the USB-attached device) follows. There is an implication that this is always an inferior method due to the non-real-time operating system used on the host end. Where this presumption falls short is when it fails to recognize that a synchronous system can use other modes of transfer, where the control of the clock is not necessarily the sole domain of the host.
Second, in an asynchronous transfer, there are multiple clock-generation schemes that can be utilized. There can be any number of buffers on both the host and client end. These buffers can be clocked by a number of different sources. The source of the clocking can be accomplished by a number of different techniques, some of which include things like a recovered and regenerated clock, an autonomous locally generated clock, and varying degrees of mixed schemes. One could also lump the use of an SRC into the asynchronous camp, but this fails to acknowledge that in this approach clock errors are simply exchanged for data errors with little real improvement.