Computer based Hifi

[Idiocratease]

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]

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.

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]

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]

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]

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.

 

[Idiocratease]

Well I will take a look. I have seen a lot of people raving about the quality etc. Cheers, Alan

 

[lazycatken]

Since the USB receiver only has to handle these 3 frequencies, the clocking to the separate DAC IC has almost no jitter.

I can't see any reason could result in this conclusion...
For instance, CD player only has to do 44.1KHz. Does this means CD player could be jitter free?
Check these
Asynchronicity: A USB Audio Primer | Computer Audiophile
Computer Audio Asylum - Steve read the post again - Gordon Rankin - November 02, 2009 at 07:03:40
No matter which circuit/solution, jitter must be taken care.

S/PDIF actually has to be sync'd to the exact frequency of the transport

That is so called PLL. Normally, it's done by S/PDIF receiver IC, e.g. CS8414.
And then, a clock is generated(according to S/PDIF) and send to DAC.
Problem is PLL can't generate low jitter clock...That's why a buffer and a separate precise clock is introduce in QDB76.

(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.

Using USB doesn't mean this...
Using Async mode USB and a precise clock could do this.

I guess, the statement of the article is just to give a simple explanation about the advantage of USB. But not precise.

Async USB is a good total solution, but only works for USB/PC. Buffer/async clock works for all. Although, the difference between signal source and the clock for DAC always results in buffer underrun/overflow. A longer buffer can simply make this problem happens once per couple minutes.

IMHO, I'll choose optical link + buffer/async clock to avoid electric noise from source. You know, such noise is hard to filtered out by circuits.

 

[Idiocratease]

Hi Lazycatken, It's complex for sure (to complex for me actually). The parts you picked up on were quotes I from articles rather than my opinion.

However, I can assure you that I am checking the optical route more carefully and awaiting a Wireworld Supernova 6, which a pretty decent cable. I will come back to you after I have listen properly. Cheers,

 

[lazycatken]

I can assure you that I am checking the optical route more carefully and awaiting a Wireworld Supernova 6, which a pretty decent cable. I will come back to you after I have listen properly. Cheers,

Check this. http://cplay.sourceforge.net/pmwiki.php?n=CMP.04BitPerfect?
I made a test, got the same result.
My Toslink cable is cheap, made of plastic, 6 meters long!

Longer Toslink cable indeed results in poorer signal, but not error, just jitter. Such issue should not happen on your QDB76.

 

[phofman]

Check this. http://cplay.sourceforge.net/pmwiki.php?n=CMP.04BitPerfect?
I made a test, got the same result.
My Toslink cable is cheap, made of plastic, 6 meters long!

Longer Toslink cable indeed results in poorer signal, but not error, just jitter. Such issue should not happen on your QDB76.

The test results described on CMP are not that impressive, it is the only expectable result unless something is fundamentally wrong. IMO the upsampling should have been done to 24 bits only, eliminating thus the speculations about reasons of the LSB variations. In such case a single-bit identical result would be the only tolerable result for a proper digital loopback. There are no clock collisions, the whole chain is slaved to RME clock, no non-linearity issues in AD/DA conversions. Real-time upsampling is no major load for a resonably modern unloaded CPU, thus no underruns should happen.

OTOH, the 6 meters optical cable is a nice addition to the test conditions.

 

[lazycatken]

IMO the upsampling should have been done to 24 bits only, eliminating thus the speculations about reasons of the LSB variations.

Ya...That's so strange... I can't realize why cMP guys did the 44.1K -> 96K upsampling... In my test, due to driver issue, I did 16bits -> 24bits. No upsampling.

To Idiocratease,
Check these graphs,
http://3.bp.blogspot.com/_QtIX994Ul...1600/EMU-0404+Toslink+vs+Coaxial+phase+FR.png
It's impulse response of my system, EMU-0404 USB sound box as digital source, AK4380 as DAC. The two graphs show phase frequency response of Toslink & coaxial cable.

 

[Idiocratease]

Y
To Idiocratease,
Check these graphs,
http://3.bp.blogspot.com/_QtIX994Ul...1600/EMU-0404+Toslink+vs+Coaxial+phase+FR.png
It's impulse response of my system, EMU-0404 USB sound box as digital source, AK4380 as DAC. The two graphs show phase frequency response of Toslink & coaxial cable.

Hi There... I have not disappeared just listening to stuff, upgrading OS ect., and I'll come back you on the optical cable issue soon...

On your graphs.. I'm not an electronics whiz, have you analyzed the properties of the digital signal ?? ... I'm assuming these were not measured in the analogue domain (despite the fact that you have a freq x axis)... So I'm wondering exactly what you measured.... and I'm very interested in the difference you appear to have captured .... is the timing of the pulse slowing in the co-axial cable cf the optical... i.e. is the edge being more compressed at higher frequency, or being slowed down causing the phase to shift...?

 

[lazycatken]

On your graphs.. I'm not an electronics whiz, have you analyzed the properties of the digital signal ?? ... I'm assuming these were not measured in the analogue domain (despite the fact that you have a freq x axis)... So I'm wondering exactly what you measured.... and I'm very interested in the difference you appear to have captured .... is the timing of the pulse slowing in the co-axial cable cf the optical... i.e. is the edge being more compressed at higher frequency, or being slowed down causing the phase to shift...?

Well, the test is not well controlled. Just to show some potential possibility...
Here's the configuration. EMU-0404 USB sound box as signal source, connects AK4380 DAC via Toslink or coaxial cable. The analog output signal of AK4380 is connected to EMU-0404 analog input via a Mogami cable, so called microphone cable, single end. The graphs are generated in process of impulse response measurement. A log sine sweep, 10Hz~22KHz, as test signal.

Since EMU-0404 analog input and Mogami cable are not perfect, we can see some phase shift in the lower end of the graphs.
Per higher end, as I mentioned, we can expect signal goes through digital cable without any error. Thus, the only issue left, per the difference between Toslink & coaxial, is jitter. AK4380 can not immune from jitter... BTW, any electric noise in the system could result in more or less phase shift. For example, disable a ground-lift of EMU-0404, resulted in more phase shift. Use MacBook Pro or Asus M4E got different result.

From the graphs, I can't say which one is better, since my equipments are not calibrated. But from the point of view of noise, I tend to use the cable introduced less noise. That should be Toslink.

 

[Charles Darwin]

A bit late to the thread but FWIW I use a quadcore MacPro, iTunes (whose folder resides in its own WD RAID edition HD), connected via FireWire to an Echo Audio AudioFire12 which is set to 24/88.2.
I rip my cds in iTunes to AIFF.
The result sounds better (read: cleaner) to me than any cd player I ever had in my house and it took almost 5 minutes to set up.

 

[Idiocratease]

...

From the graphs, I can't say which one is better, since my equipments are not calibrated. But from the point of view of noise, I tend to use the cable introduced less noise. That should be Toslink.

Ok, so it's the analogue frequency response you're measuring from the DAC.
I'm surprised any difference between the two cables is visible at all on the graphs.

Anyway, going back the to Coax vs Toslink. I know it's been a couple of weeks of silence from me, but I have taken your comments seriously (thanks). And I promised to look into your suggestion more closely after my initial rejection of Toslink.

As I mentioned I got hold of a decent quality optical cables (Wireworld Supernova 6)

What's complicated matters, is I also set up a dual boot with XP and the new Window 7. And I didn't have a sound card for Win 7, so used the USB output into my DAC (Chord QDB76). Well I was amazed by how good it sounded!

It was immediately clear to me that despite what Marian say there is subtle corruption of the data with XP and the Marian Marc 2. Irritating things I heard on my music which I've always thought were 'problems' in the original mastering, turned out to be subtle high frequency grainy glitches introduced under XP.

So still trying to test what you say about benefits of galvanic isolation that Toslink brings (with a re-clocking DAC, to eliminate the higher jitter from the optical cable).....

... I checked the chip on the QDB76. It's a PCM2704. So I figured I needed a simple USB --> Toslink converter to insert an optical path into the system. I tried a U-Control UCA202 USB, but this did not sound so good (I opened it up and it actually contains a PCM2902; I'm not sure if that's the cause). So I then bought a Trends Audio UD-10.1 USB Audio Converter. This does actually contain a PCM2704 chip, exactly the same as my DAC. So 'in principle' should eliminate all variables except the Toslink circuit and optical path (anyone else reading this, please note my DAC is a re-clocker).

Well, it certainly sounded good. I'm not sure if any differences I hear are real or imagined.. However, the Trends Audio kit had problems, kept erroring with the USB system on the PC, sometime was not recognised on re-boot. And actually was not a brand new item when it was shipped to me... So it's gone back for a refund. Probably just a faulty unit.

Well this left me wondering about getting an good optical signal from Windows 7 (and the Realtek Toslink on the MB is not supported yet). I had taken against the Trends Audio unit by now.

I did a bit of digging, and bought a Creative X-Fi Titanium (I know creative have a bad name, and my past experience with them is bad too), but it was not so expensive and worth a punt I figured... Well, it turns out these cards have a 'bit-matched' option. It sound really great, works beautifully under Win 7, and I now have the DAC galvanically isolated from the PC.

Now don't have any issues with using the Toslink and more importantly I've almost by accident learned the Window 7 is a massive improvement to the audio quality (I have dabbled with Vista in the past but was glitchy, so I was not expecting much from 7). So if anyone is reading this rambling story here are the conclusions...

AUDIO CONCLUSIONS

Window 7 = Really very good
Toslink (supernova 6 anyway) into Reclocking DAC = Very good, probably better than co-ax
Creative X-Fi = double plus good

Hope this is of interest