Computer based Hifi

[Idiocratease]

Originally Posted by lazycatken

My source is MacBook Pro.

And set output as 88.2. Then played music by Audacity 1.3.9. Made comparison between fast & high-quality sinc sampling rate conversion setting. High-quality sinc was indeed better.

....

I also tried this on an Accuphase DP-500 CD player, which can work as a DAC. Got the same result. You know this player is not cheap...

That's interesting, cf what I observe on my system (XP/PC), when there is a definite reduction of quality with increasing the sample rate above the native rate (44.1KHz). I no well what's behind this as I've been in touch with Marian support (Marian Marc 2 is my soundcard). It's because sample rate conversion goes via windows kernel mixer, which is not good.

But as you are using a Mac, thinks will (I suspect) be very different, and you may well benefit for the interpolation of the native data. My DAC (QDB76) does huge amount of upsampling and transient alignment. I have never heard such clarity from a 'CD Quality source' as from this DAC.

I've enjoyed the discussion between us on this!

[lazycatken]

Originally Posted by Idiocratease

That's interesting, cf what I observe on my system (XP/PC), when there is a definite reduction of quality with increasing the sample rate above the native rate (44.1KHz).

That's why I tried Audacity. By setting OS sampling rate to 88.2KHz, Audacity was in charge of over-sampling process. Thus, you can skip Windows' build-in over-sampling process.

Originally Posted by Idiocratease

My DAC (QDB76) does huge amount of upsampling and transient alignment. I have never heard such clarity from a 'CD Quality source' as from this DAC.

A review on a magazine AudioArt(Taiwan) also mentioned about the clarity of QDB76.
As I know, so far, I'm not an expert of this field, oversampling is introduced for digital anti-aliasing filter.

BTW, on Taipei 2009 HiFi show, I heard most clear sound of the show from PS audio PerfectWave, which also puts a lot of effort on jitter elimination.

Well, we have gone too far away from the subject of this thread, but I believe, jitter elimination is a key point of computer based HiFi. I had worked in PC industry more than 10 years. I'm sure those PC makers will not put much effort on audio quality. We have to take care by ourselves. So far, seems like optical link + buffer + async precise clock is a good choice...

[billyk]

Don't forget USB, I think USB has an undeservedly bad reputation. It passes the data, it is up to the device receiving the data to deal with it in an appropriate fashion to deliver good sound. Below is a quote from AMB Labs regarding the new Y-2 or Gamma-2 DAC. It has a USB input along with coax and optical. Notice the ASRC and clocking.

On the γ2 board, the digital audio stream is upsampled to 24-bit 96KHz by an asynchronous sample rate converter (ASRC) and then converted to analog with Wolfson's top-of-the-line ΔΣ oversampling DAC chip. An onboard ultra-low jitter oscillator provides the master clock for the ASRC and DAC chips

[Idiocratease]

Originally Posted by billyk

Don't forget USB, I think USB has an undeservedly bad reputation. It passes the data, it is up to the device receiving the data to deal with it in an appropriate fashion to deliver good sound. Below is a quote from AMB Labs regarding the new Y-2 or Gamma-2 DAC. It has a USB input along with coax and optical. Notice the ASRC and clocking.

Hi Billyk, actually you touch on something I have been wondering about. Is the data transfer exactly the same as e.g. with a memory stick ? I wonder because the DAC needs to know the incoming data sample rate, and I wonder if the data is transferred at this rate e.g. 44.1 KHz--> I suppose this is 705.6 Kbps (for a 16 bit signal) vs. data bursts i.e. upto 480 Mbps with normal USB devices).

If this is how the data is metered out, then souce clock jitter would be an issues with USB, unless the data is buffered and re clocked in the DAC (like in my DAC).

Do you happen to know ?

[billyk]

Well I spent some hours attempting to come up with some concrete info for us and ended up more confused than ever. My conclusion was that re-clocking the data and a good clock are essential for using a USB type DAC, so my thoughts on the Gamma 2 hold. Here is an article by John Swenson that I copied from The Audio Asylum that describes the USB spec and modes of transfer that I found the easiest to understand. Hope it helps.

Of course it has nothing to do with bit perfectness, its purely a jitter issue. It all comes down to the USB audio spec and how that has been implemented in the available chips.

The USB audio class implementation uses the isochronous mode of data transfer over the USB bus, with three possible types of synchronization:

synchronous, adaptive and asynchronous. I will go over these in detail a little further down, covering how they work and their jitter rammifications.

But first some detail on isochronous mode and covering some myths about USB. The USB bus works very differently than an ethernet connection works and this has given rise to some erroneous assumptions I hear a lot of around here. First off the host (computer) is in complete control of the bus, there is no way too many devices trying to talk at once can "overload" the bus such as can happen on an ethernet. Data is sent out in frames that go out every millisecond. This happens whether there is any data in them or not. The rate at which the frames go out is determined by the oscillator in the host transmitter, not by the speed at which the computer is running, or the software running on it. Some piece of software bussily running in the background cannot "slow down" the bus. It might prevent a program from keeping up with the bus (providing data to it) or accepting data from it, but the data rate on the bus stays constant (or at least fairly constant within the limits of the oscillator in the host PHY)

Now on to isochronous, this means that the host reserves bandwidth on the bus for an endpoint. (your DAC is an endpoint) This is easy for it to do since it is in complete control of the bus, nobody else can "steal" it. It doesn't matter that you have a 300gig hard drive, a scanner, a mouse or whatever else on the bus, once an isochronous endpoint is setup they all have to work around it, they get whats left over. If you try and setup too many isochronous endpoints such that the bus cannot handle it, the host will not allow them all.

One interesting tidbit about isochronous streams is that there is no error correction. There is a rudimentary error detection, but no mechanism for doing anything about it, no retries or ECC codes. I read somewhere that its estimated that for a 44.1 stream running 24 hours a day there will be an error about once a month or so. The standards committee did not consider this worth doing anything about. I guess if you detect an error you can either flash a light on the front pannel to let people know an error occured, or you can just play the previous sample. (or maybe interpolate with the next)

Now on to the fun part, the syncronization modes. In all casses the data from the bus goes into a buffer and gets clocked out by a clock, how that clock is generated and how it interacts with the bus is the differences between the modes.

Synchronous: in this mode the readout clock is directly derrived from the 1KHz frame rate. There is a PLL that takes in the start of frame signal and genrates a clock. Using this scheme its rather difficult to generate 44.1, but very easy to generate 48KHz. This is a primary reason why many early USB audio devices only supports 48KHz, they used this mode. As you can guess this mode is very susceptible to jitter on the bus, pretty much anything that causes the output from the host to be jittered (PS noise, vibrations, interference etc) AND things that can cause jitter on the interconnect (interference, reflections, ground noise etc) will wind up with jitter on the readout clock. This is a VERY poor mode to use for decent quality audio.

Adaptive: in this mode the clock comes from a separate clock generator (usually implemented as a PLL referenced by a crystal oscillator) that can have its frequency adjusted in small increments over a wide range. A control circuit (either hardware or firmware running on an embedded processor) measures the average rate of the DATA coming over the bus and adjusts the clock to match that. Since the clock is not directly derived from a bus signal it is far less sensitive to bus jitter than synchronous mode, but what is going on on the bus still can effect it. Its still generated by a PLL that takes its control from the circuits that see the jitter on the bus. Its a lot better than synchronous mode, but still not perfect by a long shot. This is the mode that MOST USB audio devices use today.

Asynchronous: in this mode an external clock is used to clock the data out of the buffer and a feedback stream is setup to tell the host how fast to send the data. A control circuit monitors the status of the buffer and tells the host to speed up if the buffer is getting too empty or slow daown if its getting too full. Note this is still isochronous, the host is continuousley sending samples, there is no "per packet handshake" going on. Since the readout clock is not dependant on anything going on with the bus, it can be fed directly from a low jitter oscillator, no PLL need apply. This mode can be made to be VERY insensitive to bus jitter.

The reality: There are NO USB audio chips that out of the box support asynchronous mode! If any one here is aware of any please let me know. I have researched the field quite thoroughly and not found any. There are a few that theoretically do support it, but their firmware has to be rewritten to support asynchronous transfer. I have been trying to do this for one of these chips for the last several months and have been running into a lot of roadblocks. Sometime in the future I hope to get it working, but for now I have to live with chips that support adaptive mode.

These adaptive chips are not bad, they actually have quite good jitter performance, much better than I thought they would have when I started working with them. But its not perfect, or really even close. Because of this the DAC is still sensitive to whats going on with the cable and the host, not a lot, but it is definately there.

As the quality of the power supply, DAC board layout and output stage have increased the level of grundge and noise from these sources on the output signal have decreased to the point where the jitter effects are a larger percentage of problems with the sound. You probably will have a hard time hearing these effects on a stock transit for example, there is too much else going on that is masking these effects. But once this other stuff is diminsihed significantly the effects of the interface jitter are much more noticeable.

Of course there is another way to deal with this, throw out the USB audio spec and write your own using the bulk protocol. Of course this means you have to write your own windows, MAC and linux drivers, AND your own firmware for a generic USB interface chip. It CAN be made to work and if done right could provide a very low jitter interface, but it is one heck of a lot of work, one I don't have the time for (unless someone here is willing to support me and my familly so I can spend full time on this)

I guess thats enough of my soapbox for now, I'll get off and return you to your regularly scheduled assylum.

John S.

[Idiocratease]

Originally Posted by billyk

Well I spent some hours attempting to come up with some concrete info for us and ended up more confused than ever. My conclusion was that re-clocking the data and a good clock are essential for using a USB type DAC, so my thoughts on the Gamma 2 hold. Here is an article by John Swenson that I copied from The Audio Asylum that describes the USB spec and modes of transfer that I found the easiest to understand. Hope it helps.

This is complicated, and I confess I am still not sure if the source clock plays a part in the USB signal....but I will certainly listen to my USB input on the DAC. And I have ordered a good quality Toslink cable to re-test the optical based on an earlier discussion....

I appreciate your reply and will continue to look into this.

Thanks,

[Idiocratease]

Originally Posted by billyk

Well I spent some hours attempting to come up with some concrete info for us and ended up more confused than ever. My conclusion was that re-clocking the data and a good clock are essential for using a USB type DAC, so my thoughts on the Gamma 2 hold. Here is an article by John Swenson that I copied from The Audio Asylum that describes the USB spec and modes of transfer that I found the easiest to understand. Hope it helps.

Hi Again!! I did a little bit of searching and I found the following:-
6moons audio reviews: Wavelength Audio Brick USB DAC

I was quite encouraged by reading this:-
"About USB's advantage over S/PDIF? The latter is unidirectional. USB is not to insure that the data on the hard-drive is identical to what streams out. According to Gordon, "the USB interface is asynchronous to avoid the clocking problems of S/PDIF. The Brick tells the computer it can do 16-bit audio at 32K, 44.1K and 48K. Since the USB receiver only has to handle these 3 frequencies, the clocking to the separate DAC IC has almost no jitter. S/PDIF actually has to be sync'd to the exact frequency of the transport (i.e. if the transport is working at 44.0896K instead of 44.1K, the DAC has to sync to that frequency). Therefore, the jitter problems of S/PDIF almost vanish using USB. With USB, we have a zero error protocol to link the computer to the DAC and very low jitter."

However, at the end of the article I read the following:-

"Basically the problem with PCs aroused in XP (I think this is when it started or maybe in a later version of Media Player) is the Kmixer. The Kmixer looks at the audio output and determines the highest rate. Then it automatically (even if it is 1:1) upsamples any sample output to USB to the highest rate (48/16 for my stuff). You can use ASIO4ALL with applications like Meedio, Foorbar and other front end programs. This will bypass the terrible Kmixer to result in superior output signal."

This plays to my concern about the path of the signal inside the PC, before it even gets to the USB plug... I earlier mentioned that I was not 100% happy with the sound I hear from the UBB (9th Nov, 06:57 PM), and I wondered if the routing inside the PC (kmixer/drivers etc) might be the root of the problem. This article seems to support this possibility.

I know for a 100% fact that up-sampling in via the kmixer has a deleterious affect on the sound (when in should improve, or at least do no harm). So my gut feeling is even a 1:1 sampling in the kmixer might have an adverse effect.

At least I know using the Marian Marc 2 soundcard that the kmixer is avoided...

I suppose then we should be looking for USB drivers which are audiophile and avoid the kmixer? I shall start to look....

[billyk]

One thing for sure, regardless of what interface, you need to try to keep the signal as unadulterated as possible.The last thing you want is the OS doing what some one else told it it was "best" to do IE: kmixer.
To that end, on a PC, with windows, use something like foobar that allows you to use ASIO4all, WASPI or some type of Kernel Streaming. I use foobar and ASIO4all. It works well and is fairly simple to use. I use it for all interfaces and all of my DACs

[Idiocratease]

Hi John, yes, makes perfect sense. I like to use windows media player. I did find an ASIO driver for this, but it did not work well.... I have 0.5 TB of media files, and windows media player does provide a great interface, but it also is a limitation... I'm wondering if I should start to chase microsoft about USB drivers to aviod the kmixer...

Interesting stuff... Thanks.

[billyk]

Give foobar a shot. I have a bit over 2Tb of stuff and have really kind of given up on the use of a music player to manage it. Most of my collection is live music. I arrange my music by live or commercial, then by band. If live after band it is broken down into years and venues. This is how I store it on my disks. To play I choose what I want and drag and drop into foobar to play. Sometimes I'll drag a few days worth over and listen that way. Then I just highlight and delete then drag in some new stuff (it doesn't delete the files just the list). I convert stuff to mp3 for my portables and tag as needed to get it usable there. Kinda hit or miss but works well for me as I am a bit hit or miss myself.
Anyway give foobar 2000 a try, you can then configure your outputs with ASIO4all be they USB, spdif, etc. I think you will be pleased.