Jitter problem

[One and a half]

Nevertheless, the Intona USB Isolator that I ordered may do a much better job of reclocking the audio stream, which will hopefully make all such optimizations an tweaks unnecessary. We'll see..

 

Never mind.

[Abtr]

Never mind.

According to the Intona website:

 

The 7054-based USB Hi-Speed Isolator is a phy-level receiver/isolator/reclocker/repacketizer working at a bidirectional bandwidth of 480 MBit/s. It receives and transmits USB data using a dedicated ULPI-transceiver, buffers and translates by our proprietary logic using FPGA technology and isolates using industry-leading RF-type isolators by Silicon Labs with least possible capacitance. It does not translate or distort data packets like a hub but does reproduce and reclock the original data by 100%.

(Intona ? Häufig gestellte Fragen & Antworten)

[mansr]

A typical Windows PC has many simultaneous processes (programs and services) running in thousands of threads. Reducing the number of processes to a minimum and raising the priority of audio-processes, will minimize the number of OS interrupts of audio processing which will reduce timing errors (jitter) in the audio stream.

 

That's not how things work. A sound card has a crystal oscillator running at some multiple of the sample rate. As long as the software (player and drivers) can keep the sound card FIFO filled, the number of other processes or interrupts make no difference.

 

Fidelizer, XXhighend, Jplay, etc. do just that and this will improve sound for simple adaptive USB.

 

Adaptive USB uses isochronous transfers. This means a packet of data is sent at pre-set intervals, all managed by hardware. The software only has to make sure the data is ready on time. Since data is sent in bursts, clock recovery on the receiving end is harder than with a continuous stream (e.g. S/PDIF), so there will likely be more jitter. The USB host timing probably also has more jitter to begin with. However, none of this is caused by software. If the clock were generated by software, it would much, much worse.

[Abtr]

That's not how things work. A sound card has a crystal oscillator running at some multiple of the sample rate. As long as the software (player and drivers) can keep the sound card FIFO filled, the number of other processes or interrupts make no difference.

Would that make all audio optimization tools and settings useless? And doesn’t my DAC's USB 2.0 driver run on the CPU (directed by the system clock) making it subject to thread scheduling and time slicing (in the presence of many other concurrent processes) which might introduce timing errors?

[mansr]

Would that make all audio optimization tools and settings useless?

 

Removing unnecessary processes lowers the system overhead which mainly does two things:

 

1. Reduces the risk of buffer underruns (drop-outs). This is only important if you're doing CPU-intensive filtering or otherwise running near full CPU load. Simply playing back a FLAC file uses a fraction of a percent of the CPU time on a modern system.

 

2. Reduces noise from system components that might get coupled to the analogue side by various routes. Such noise can often be easily heard from motherboard built-in sound cards, less often with add-on PCI cards. External DACs are the least sensitive, and any noise they do pick up usually originates in the USB host controller itself independently of general system activity. Using a dedicated USB host port for the DAC is always a good idea.

 

And doesn’t my DAC's USB 2.0 driver run on the CPU (directed by the system clock) making it subject to thread scheduling and time slicing (in the presence of many other concurrent processes) which might introduce timing errors?

 

Asynchronous USB DACs (USB Audio Class 2.0) operate much more like a PCI sound card. They have a local clock that runs independently of anything in the PC. Whenever the buffer (FIFO) in the DAC runs low, it requests more data from the host, and as long as the host (player and driver) responds before the buffer runs out entirely, everything is fine. A buffer underrun results in a very obvious drop-out, not some subtle jitter effect.

 

Getting back to your problem, your measurements show a clear difference, but with so many variables, it's hard to say what the root cause might be. That's why I've been proposing tests to eliminate as many sources of variation as possible. If you want to get to the bottom of it, I recommend that you try some of the suggestions and report back what you find. Recording the DAC output directly instead of going through speakers and microphone ought to be possible with whatever gear you're using, and it should give you much cleaner readings.

[Abtr]

OK, thanks for the insights, mansr.

 

… Recording the DAC output directly instead of going through speakers and microphone ought to be possible with whatever gear you're using, and it should give you much cleaner readings.

Is there software that can do this? And what would it add to the current conclusion that the jitter originates somewhere in the PC/USB system and not in the MX-DAC's conversion circuits and opamps?

[mansr]

Recording the DAC output directly instead of going through speakers and microphone ought to be possible with whatever gear you're using, and it should give you much cleaner readings.

 

Is there software that can do this? And what would it add to the current conclusion that the jitter originates somewhere in the PC/USB system and not in the MX-DAC's conversion circuits and opamps?

 

What did you use to record the microphone? If that hardware has a line-level input, connect a cable directly from the DAC analogue output to this (instead of to an amp) and repeat whatever you did before. This in itself won't provide any new information, but it will give a much better measurement of the DAC output without distortions from the speakers or the room.

[Abtr]

What did you use to record the microphone? If that hardware has a line-level input, connect a cable directly from the DAC analogue output to this (instead of to an amp) and repeat whatever you did before. This in itself won't provide any new information, but it will give a much better measurement of the DAC output without distortions from the speakers or the room.

To record the microphone output I used software for measuring analogue sound reproduction and room acoustics (Omnimic V2), which is calibrated to use specific audio test tracks (provided on CD and online as wav files) and a specific (calibrated) microphone. Unfortunately, there's no way to connect the DAC's line level output to it.

 

I wouldn't worry about the quality of the measurements though. They're clear enough to me.. And to eliminate room acoustics I can place the microphone at 10 cm distance from a speaker and re-measure one channel. I guarantee that will look practically the same as a similar measurement directly from the DAC's line level output.

[sandyk]

As long as the software (player and drivers) can keep the sound card FIFO filled, the number of other processes or interrupts make no difference.

Get into the real world for a change. That's rubbish. Even a scheduled email check may cause small interruptions and audible clicks if the email client is open during listening.

[mansr]

Get into the real world for a change. That's rubbish. Even a scheduled email check may cause small interruptions and audible clicks if the email client is open during listening.

 

Only if the computer is underpowered or misconfigured, and be that as it may, it's not related to the problem here.

[JohnSwenson]

Asynchronous USB DACs (USB Audio Class 2.0) operate much more like a PCI sound card. They have a local clock that runs independently of anything in the PC. Whenever the buffer (FIFO) in the DAC runs low, it requests more data from the host, and as long as the host (player and driver) responds before the buffer runs out entirely, everything is fine. A buffer underrun results in a very obvious drop-out, not some subtle jitter effect.

 

 

This is not the way asynchronous USB actually works.

 

In both adaptive and asynchronous mode there is a continuous stream of audio samples, it is exactly the same for both modes. The packet rate is fixed, the audio data rate is determined by the number of samples per packet. This doesn't give enough granularity so the number of samples is varied per packet. For example 5 packets of 10 samples, then one packet of 11 samples, then 6 packets of 10 samples etc. This can give fine grain control of the overall data rate.

 

At the start of the stream the host figures out what this pattern is going to be, for adaptive it stays that way. For asynchronous mode the DAC keeps track of its buffer and if it starts to get low it sends a feedback packet to the host telling it to speed up slightly, the host then slightly changes the packet pattern such as to increase the average data rate. The inverse happens when the buffer gets too full.

 

So for both adaptive and asynchronous modes audio samples are continuously being sent over the bus, at no time is the host waiting for the DAC to tell it to send more data.

 

This is very different than some other packet based systems that always send a packet with a fixed amount of data, but vary how often those packets get sent, usually with some for of flow control to stop or start the sending of packets.

 

This feedback packet going the other way can cause all kinds of interesting problems. Some USB hardware implementations handle the isochronous stream nicely in hardware, but don't know anything about the feedback packet. When this comes along the hardware has to fire off an interrupt to deal with it. If the processor is busy, handling this interrupt can sometimes not go correctly and the change in data rate doesn't happen in time which causes an xrun in the DAC. Sometimes this even causes the feedback packet to not get dealt with at all, causing all kinds of problems.

 

The above problems seem to happen more often in embedded processor systems, primarily because corners were cut in the USB implementation to save money, putting some functionality in the software domain rather than in hardware.

 

John S.

[kumakuma]

Get into the real world for a change. That's rubbish. Even a scheduled email check may cause small interruptions and audible clicks if the email client is open during listening.

 

I have no problem playing DSD files on my office machine with five or six applications including email open and Time Machine doing backups in the background.

 

Maybe you need to get yourself a Mac.

[Abtr]

… The above problems seem to happen more often in embedded processor systems, primarily because corners were cut in the USB implementation to save money, putting some functionality in the software domain rather than in hardware.

John S.

Hi John,

 

So are you saying that my jitter problem may be caused by a faulty USB 2.0 implementation in the Musical Fidelity MX-DAC?

[mansr]

This is not the way asynchronous USB actually works.

 

In both adaptive and asynchronous mode there is a continuous stream of audio samples, it is exactly the same for both modes. The packet rate is fixed, the audio data rate is determined by the number of samples per packet. This doesn't give enough granularity so the number of samples is varied per packet. For example 5 packets of 10 samples, then one packet of 11 samples, then 6 packets of 10 samples etc. This can give fine grain control of the overall data rate.

 

At the start of the stream the host figures out what this pattern is going to be, for adaptive it stays that way. For asynchronous mode the DAC keeps track of its buffer and if it starts to get low it sends a feedback packet to the host telling it to speed up slightly, the host then slightly changes the packet pattern such as to increase the average data rate. The inverse happens when the buffer gets too full.

 

Thanks for the clarification/correction. My explanation was indeed somewhat simplified. The point I was trying to get across was that in asynchronous mode, the DAC controls the data rate, in adaptive mode the host does.

 

So for both adaptive and asynchronous modes audio samples are continuously being sent over the bus, at no time is the host waiting for the DAC to tell it to send more data.

 

The bus is (potentially) shared with other USB devices, and even if no other devices are present, the DAC doesn't use the full data rate, so there will be gaps between packets. This is different from links such as S/PDIF which carry a single, uninterrupted bitstream.

 

This is very different than some other packet based systems that always send a packet with a fixed amount of data, but vary how often those packets get sent, usually with some for of flow control to stop or start the sending of packets.

 

This feedback packet going the other way can cause all kinds of interesting problems. Some USB hardware implementations handle the isochronous stream nicely in hardware, but don't know anything about the feedback packet. When this comes along the hardware has to fire off an interrupt to deal with it. If the processor is busy, handling this interrupt can sometimes not go correctly and the change in data rate doesn't happen in time which causes an xrun in the DAC. Sometimes this even causes the feedback packet to not get dealt with at all, causing all kinds of problems.

 

Failure to handle the feedback packet should only happen on an overloaded or misconfigured system, and the result of this will be an obvious skip or dropout, not low-level jitter.

 

The above problems seem to happen more often in embedded processor systems, primarily because corners were cut in the USB implementation to save money, putting some functionality in the software domain rather than in hardware.

 

The Raspberry Pi is notorious in this regard. I don't know of any USB implementation quite as terrible as that one.

[pipis2010]

Thanks for the clarification/correction. My explanation was indeed somewhat simplified. The point I was trying to get across was that in asynchronous mode, the DAC controls the data rate, in adaptive mode the host does.

 

 

 

The bus is (potentially) shared with other USB devices, and even if no other devices are present, the DAC doesn't use the full data rate, so there will be gaps between packets. This is different from links such as S/PDIF which carry a single, uninterrupted bitstream.

 

 

 

Failure to handle the feedback packet should only happen on an overloaded or misconfigured system, and the result of this will be an obvious skip or dropout, not low-level jitter.

 

 

 

The Raspberry Pi is notorious in this regard. I don't know of any USB implementation quite as terrible as that one.

 

Intersting statement concerning the Pi, especially since there are people praising its sound (along with its specific add-on DAC) connected to a NAS.

 

Apparently, everything is subjective in this field

 

 

Sent from my iPhone using Computer Audiophile mobile app

[mansr]

Intersting statement concerning the Pi, especially since there are people praising its sound (along with its specific add-on DAC) connected to a NAS.

 

The RPi USB implementation is terrible but still adequate for shuffling bits to a DAC, apparently.

[Abtr]

Well, the good news is that the Intona USB Isolator definitely improved overall sound quality. It's a bit like the effect of correctly connecting the AC mains phase of certain audio components versus incorrectly connected phase. SQ of streaming music through the MX-DAC has now become somewhat acceptable..

 

The bad news is that the Intona did not reduce the jitter at all, it's simply unchanged. I think I tried everything possible at the PC site, I even ran Fidelizer (in audiophile mode) but to no avail. In my mind this only leaves the MX-DAC USB 2.0 driver and/or the USB 2.0 implementation in the DAC itself as possible culprits. I guess the only way to find out is by trying another USB DAC..

[pipis2010]

Well, the good news is that the Intona USB Isolator definitely improved overall sound quality. It's a bit like the effect of correctly connecting the AC mains phase of certain audio components versus incorrectly connected phase. SQ of streaming music through the MX-DAC has now become somewhat acceptable..

 

The bad news is that the Intona did not reduce the jitter at all, it's simply unchanged. I think I tried everything possible at the PC site, I even ran Fidelizer (in audiophile mode) but to no avail. In my mind this only leaves the MX-DAC USB 2.0 driver and/or the USB 2.0 implementation in the DAC itself as possible culprits. I guess the only way to find out is by trying another USB DAC..

 

Why don't you just try Daphile OS and see what happens? You may be surprised at the result...

 

 

Sent from my iPhone using Computer Audiophile mobile app

[sandyk]

Abtr

 

BTW, did you also try running your notebook on battery supply for the tests ?

 

Regards

Alex

[Abtr]

BTW, did you also try running your notebook on battery supply for the tests ?

Yep, no improvement.

 

Why don't you just try Daphile OS and see what happens? You may be surprised at the result...

Ultimately I may try a solution like that. But I’m not giving up yet. I’m quite convinced that somehow the MX-DAC USB interface causes the problem. So I'm now planning to order a good USB to S/P-DIF (Toslink or coaxial) converter like this: Anedio Affordable High-End Audio : U2 USB-to-SPDIF Converter Measurements. That way I don’t have to use the MX-DAC USB driver and USB input.

[Abtr]

Just to prove the concept I ordered a Firestone Bluekey USB to S/PDIF Converter 24Bit/192kHz (69 Euro) BlueKey

[davide256]

This is not the way asynchronous USB actually works.

 

In both adaptive and asynchronous mode there is a continuous stream of audio samples, it is exactly the same for both modes. The packet rate is fixed, the audio data rate is determined by the number of samples per packet. This doesn't give enough granularity so the number of samples is varied per packet. For example 5 packets of 10 samples, then one packet of 11 samples, then 6 packets of 10 samples etc. This can give fine grain control of the overall data rate.

 

At the start of the stream the host figures out what this pattern is going to be, for adaptive it stays that way. For asynchronous mode the DAC keeps track of its buffer and if it starts to get low it sends a feedback packet to the host telling it to speed up slightly, the host then slightly changes the packet pattern such as to increase the average data rate. The inverse happens when the buffer gets too full.

 

So for both adaptive and asynchronous modes audio samples are continuously being sent over the bus, at no time is the host waiting for the DAC to tell it to send more data.

 

This is very different than some other packet based systems that always send a packet with a fixed amount of data, but vary how often those packets get sent, usually with some for of flow control to stop or start the sending of packets.

 

This feedback packet going the other way can cause all kinds of interesting problems. Some USB hardware implementations handle the isochronous stream nicely in hardware, but don't know anything about the feedback packet. When this comes along the hardware has to fire off an interrupt to deal with it. If the processor is busy, handling this interrupt can sometimes not go correctly and the change in data rate doesn't happen in time which causes an xrun in the DAC. Sometimes this even causes the feedback packet to not get dealt with at all, causing all kinds of problems.

 

The above problems seem to happen more often in embedded processor systems, primarily because corners were cut in the USB implementation to save money, putting some functionality in the software domain rather than in hardware.

 

John S.

 

Hi John... any way to sort out if a device has good USB hardware before you buy without an audition? This could explain why USB success is variable.

[Possum Jenkins]

Yep, no improvement.

 

 

Ultimately I may try a solution like that. But I’m not giving up yet. I’m quite convinced that somehow the MX-DAC USB interface causes the problem. So I'm now planning to order a good USB to S/P-DIF (Toslink or coaxial) converter like this: Anedio Affordable High-End Audio : U2 USB-to-SPDIF Converter Measurements. That way I don’t have to use the MX-DAC USB driver and USB input.

 

I have this DAC and run Daphile, can't say anything but good things about this setup. I realise that doesn't help you but the defects you're describing using the usb input of the MX-DAC are things I don't experience. Not too long ago I had a Chord 2qute which I found way too harsh for my sensitive ears so replaced it with the mx, less harsh but no less revealing in my opinion.

 

You can burn the daphile iso using rufus as a test and it won't cost you anything (unless you don't have a usb stick), definitely worth a go.

 

I've also tried it in Windows 10 (using a diskless iscsi boot), JRiver and the Music Fidelity usb driver, seemed great there too.

 

Have you considered running without the +5v line too, I do on mine and it seems to behave ok.

[Abtr]

I have this DAC and run Daphile, can't say anything but good things about this setup. I realise that doesn't help you but the defects you're describing using the usb input of the MX-DAC are things I don't experience. Not too long ago I had a Chord 2qute which I found way too harsh for my sensitive ears so replaced it with the mx, less harsh but no less revealing in my opinion.

 

You can burn the daphile iso using rufus as a test and it won't cost you anything (unless you don't have a usb stick), definitely worth a go.

 

I've also tried it in Windows 10 (using a diskless iscsi boot), JRiver and the Music Fidelity usb driver, seemed great there too.

Hi Possum. I agree that it's a great DAC, so I really want it to work properly and I still don't see why it shouldn't do that with a Windows PC. Maybe it's an individual fault of my MX-DAC that somehow escaped quality control.. Anyway, if the coaxial connection and different USB driver don't improve sound/jitter, then I'll have to conclude that the MX-DAC is not the problem. At that point I might try Daphile. Sounds like a good idea. If it subsequently eliminates the jitter then Windows (7) must be the problem. And if it doesn’t, the PC may be the problem.

 

Have you ever optically or coaxially connected a good CD transport to the DAC? Does it sound as good as your USB connection with the same tracks? In my current setup, SQ of optical CD is clearly better than USB.

 

Have you considered running without the +5v line too, I do on mine and it seems to behave ok.

Does it improve SQ? If the DAC's USB can do without the 5V, it should be disconnected at the input connector. But I can try..

[davide256]

Well, the good news is that the Intona USB Isolator definitely improved overall sound quality. It's a bit like the effect of correctly connecting the AC mains phase of certain audio components versus incorrectly connected phase. SQ of streaming music through the MX-DAC has now become somewhat acceptable..

 

The bad news is that the Intona did not reduce the jitter at all, it's simply unchanged. I think I tried everything possible at the PC site, I even ran Fidelizer (in audiophile mode) but to no avail. In my mind this only leaves the MX-DAC USB 2.0 driver and/or the USB 2.0 implementation in the DAC itself as possible culprits. I guess the only way to find out is by trying another USB DAC..

 

Abtr, I thinked you missed John's point... the question is whether the laptop has bad USB hardware. What known good source have you tried that shows the problem follows the DAC vs the laptop??