Hi,
I am building a USB dac (dddac), and one of the components is an asynchronous USB-to-I2S board. I discovered that the Raspberry Pi actually has a direct I2S output with an option for an external clock.
In my imagination that would have less jitter than any other solution because you have 256MB worth of memory to buffer stuff in and a high speed cpu for putting stuff on the line.
I posted this on the dddac thread and supersurfer had this to say about it:
I wondered if the clock could not be on a separate power supply to reduce noise, to which he replied:
It was established that this could be used for any dac, not just the dddac so Doede suggested I start a fresh thread on this.
So what do you guys think, is it possible to use the Pi as a low jitter I2S source or is the noise generated by the CPU too big of an obstacle?
(for the sake of the discussion, please assume that I will be able to get the software side of this use the electronics to their best extent)
Kind regards,
Tinco
I am building a USB dac (dddac), and one of the components is an asynchronous USB-to-I2S board. I discovered that the Raspberry Pi actually has a direct I2S output with an option for an external clock.
In my imagination that would have less jitter than any other solution because you have 256MB worth of memory to buffer stuff in and a high speed cpu for putting stuff on the line.
I posted this on the dddac thread and supersurfer had this to say about it:
I wondered if the clock could not be on a separate power supply to reduce noise, to which he replied:
It was established that this could be used for any dac, not just the dddac so Doede suggested I start a fresh thread on this.
So what do you guys think, is it possible to use the Pi as a low jitter I2S source or is the noise generated by the CPU too big of an obstacle?
(for the sake of the discussion, please assume that I will be able to get the software side of this use the electronics to their best extent)
Kind regards,
Tinco
Last edited:
I think the problem is that you still need some mechanism to ensure the absence of buffer over- or underruns.
If the data being delivered by the USB is arriving at a slower clock rate than the I2S is clocking it out, then you must accumulate data before starting to clock it out, and no matter how big the buffer, it will eventually empty. You need prior knowledge of the duration of the track, sound, music, whatever to know how much buffer space you need to fill.
The case where data is being delivered faster than it is being clocked out is simpler to deal with in some terms, but eventually the buffer will fill. The question will still remain, how do you intend to guarantee the delivery rate is greater than the output rate?
Of course a very big buffer does give some leeway, but music playback is only one aspect. Synchronisation with video may also be required and most people would prefer that this should be automatic.
There is only really one way to deal with this problem, that is to have a master clock at the DAC and to have the data delivered on demand by the PC over the USB in the same way that printers or other devices used to control the data sent to them. Currently available generic USB drivers in Windows simply do not permit such an arrangement for devices that the drivers recognize as DACs.
If the data being delivered by the USB is arriving at a slower clock rate than the I2S is clocking it out, then you must accumulate data before starting to clock it out, and no matter how big the buffer, it will eventually empty. You need prior knowledge of the duration of the track, sound, music, whatever to know how much buffer space you need to fill.
The case where data is being delivered faster than it is being clocked out is simpler to deal with in some terms, but eventually the buffer will fill. The question will still remain, how do you intend to guarantee the delivery rate is greater than the output rate?
Of course a very big buffer does give some leeway, but music playback is only one aspect. Synchronisation with video may also be required and most people would prefer that this should be automatic.
There is only really one way to deal with this problem, that is to have a master clock at the DAC and to have the data delivered on demand by the PC over the USB in the same way that printers or other devices used to control the data sent to them. Currently available generic USB drivers in Windows simply do not permit such an arrangement for devices that the drivers recognize as DACs.
While what you say is true, this holds for all USB dacs. And it has been shown that with some buffering they work fine. The Pi has a relatively large amount of memory available for buffering. Synchronisation with video is not required.
What I am asking is wether it would be possible to use the Pi to build a I2S source that is competitive with for example the luckit WaveIO USB to I2S card.
The answer to this lies in wether the Pi can produce a clean enough signal.
What I am asking is wether it would be possible to use the Pi to build a I2S source that is competitive with for example the luckit WaveIO USB to I2S card.
The answer to this lies in wether the Pi can produce a clean enough signal.
Yes, this is why the very large majority of DACs have a clock derived from the incoming data, not an external, asynchronous clock.
Thinking about it, the RPi USB functions as a host, master, or controller device, DACs are normally slave devices.
You cannot make the RPi do what you want.
Yes, but for USB deriving the clock from the incoming data would be very jitter prone. That is why high-end DACS have elaborate buffering schemes accompanying their reclocking circuits.
It is true that the model B Raspberry Pi can only be used as a master device, but the recently introduced Model A has had the usb hub removed and can now also be used as a slave.
Anyway I would be just as happy if it did ethernet to i2s instead.
I think the best way to find out if I can reduce the jitter is to measure it. I tried googling for how to measure jitter but all I got was highlevel overviews. Does anyone here maybe know how I could generate jitter graphs? (either the eye diagrams or those bar charts?) What sort of device would I need?
It is true that the model B Raspberry Pi can only be used as a master device, but the recently introduced Model A has had the usb hub removed and can now also be used as a slave.
Anyway I would be just as happy if it did ethernet to i2s instead.
I think the best way to find out if I can reduce the jitter is to measure it. I tried googling for how to measure jitter but all I got was highlevel overviews. Does anyone here maybe know how I could generate jitter graphs? (either the eye diagrams or those bar charts?) What sort of device would I need?
Hmmm, what about dynamically (maybe stepwise) control the cpu clock? I would be most interessted in taking the data from the gpio pins rather than messing with USB... But of course, if we can get the USB to play as we wan't I maybe choose that direction instead - but KISS as always...
Last edited:
You have still not addressed the issue of buffer over- and underruns.
You will find it impossible to achieve a substantial improvement in jitter in the complex environment offered by a RPi. Low jitter (SOTA jitter) already requires custom layouts of the utmost simplicity, pared down to the minimum required to enable functionality.
The answer to this problem is not an elaborate buffering scheme and reclocking. The answer is a DAC with a low-jitter local clock and a small buffer and a data on demand delivery scheme to achieve low-latency.
Put your efforts into devising a way to achieve this, instead of a scheme which merely attempts to put a bandaid on a fundamentally broken system.
There is very little to no chance that your university will have an audio test set. Universities have generic equipment. Test sets are industry and production line specific.
You will find it impossible to achieve a substantial improvement in jitter in the complex environment offered by a RPi. Low jitter (SOTA jitter) already requires custom layouts of the utmost simplicity, pared down to the minimum required to enable functionality.
The answer to this problem is not an elaborate buffering scheme and reclocking. The answer is a DAC with a low-jitter local clock and a small buffer and a data on demand delivery scheme to achieve low-latency.
Put your efforts into devising a way to achieve this, instead of a scheme which merely attempts to put a bandaid on a fundamentally broken system.
There is very little to no chance that your university will have an audio test set. Universities have generic equipment. Test sets are industry and production line specific.
So I can imagine my university doesn't have something like this: AP High Performance Audio Analyzer & Audio Test Instruments : APX525 because it doesn't research audio signals as far as I am aware. But I2S is a digital signal, this means any digital analyzer should be able to get some data on it right? There is a whole lab that researches optical circuits that have loads of analyzers like this (I had a tour of it there, the researcher was very proud of the expensive equipment 
).
So what should I measure? I could measure the clock signal that is sent by the Pi, that's just a sinus so I could plot an FFT of it and it should just have 1 peak and the rest should be as low as possible right?
The data channel is more complex, what data should I make the Pi generate? Could I for example make it send a pattern of 1's and 0's that alternates in some pattern?
Do I have to measure the data channel? Doesn't the clock just drive the data acquisition, making it the only source of jitter?
).So what should I measure? I could measure the clock signal that is sent by the Pi, that's just a sinus so I could plot an FFT of it and it should just have 1 peak and the rest should be as low as possible right?
The data channel is more complex, what data should I make the Pi generate? Could I for example make it send a pattern of 1's and 0's that alternates in some pattern?
Do I have to measure the data channel? Doesn't the clock just drive the data acquisition, making it the only source of jitter?
Last edited:
What you are interested in is the timing purity of your word clock when it comes to jitter. Dedicated AP hardware will do it and will make it possible to get useful information out without a lot of knowledge of what you are trying to fundamentally measure. That's the beauty of dedicated boxes like the AP units. But you can surely do the same sort of measurements with a fast tektronix digital sampling scope, or an RF spectrum analyzer. Your jitter in your word clock will show up as changing sidebands in an RF spectrum analyzer I believe. You'll have to do some math to get it back into the time domain, but it's not like you have a lot of control of the jitter unless you are planning to do new layouts and hardware designs.
Also remember that your measured signal isn't really a sine wave, it's a square wave, and has lots of harmonics. All the audio ASICs that I know of, use or derive a master clock, and then divide that down to get the bit, word and L/R clocks. So you could measure the master clock. But at the end of the day, only the word clock is what triggers the D to A conversion. And that is an amplitude based threshold, so if your waveform is somewhat ratty and changes over time, you created jitter yourself. That's why proper termination on the clock lines is very important (the word clock especially).
Sheldon
Also remember that your measured signal isn't really a sine wave, it's a square wave, and has lots of harmonics. All the audio ASICs that I know of, use or derive a master clock, and then divide that down to get the bit, word and L/R clocks. So you could measure the master clock. But at the end of the day, only the word clock is what triggers the D to A conversion. And that is an amplitude based threshold, so if your waveform is somewhat ratty and changes over time, you created jitter yourself. That's why proper termination on the clock lines is very important (the word clock especially).
Sheldon
Thanks for the clear explanation Sheldon!
You are right that I don't have much control of the jitter. The Pi allows for an external clock, but from what I gather from the reactions here even if I pick a high quality clock it will still be disturbed by the Pi's circuitry, with no way to separate it from that influence.
So my goal is just to evaluate how big that influence really is. Is it terrible enough to throw in the towel and just output the data over usb to a simpler better architected circuit like the WaveIO or is it in the same quality range as the WaveIO?
You are right that I don't have much control of the jitter. The Pi allows for an external clock, but from what I gather from the reactions here even if I pick a high quality clock it will still be disturbed by the Pi's circuitry, with no way to separate it from that influence.
So my goal is just to evaluate how big that influence really is. Is it terrible enough to throw in the towel and just output the data over usb to a simpler better architected circuit like the WaveIO or is it in the same quality range as the WaveIO?
I think people are saying that if you are concerned with your timing to the point of using an external clock, you need more understanding of all aspects of the circuit. You really need to be doing a complete design. It's very possible to take the I2S signals from the rPI and buffer them and build a very respectable DAC. The question that remains is this more or less work than starting from scratch? Clearly things like Tek Scopes, AP measurement systems can have very complex digital sides (modern Tek scopes are windows PC's), and still have very good analog performance. But people did a lot of work to understand both sides and their interactions.
I stream all my music these days, and I'm using Airport Expresses into my own DACs with asyncronous sample rate conversion. If I were doing what you would like to do, I'd use the I2S output to a sample rate converter chip (CS8421) and then to a good DAC chip and analog stage. I'd pay attention to the power supplies in the clock circuit of the ASRC and all the voltages in the DAC chip as well as the transmission of the clocks between the chips.
For a look at my DAC see: Sheldon’s World Blog Archive Another Audio Digital-to-Analog (DAC) is Born
Sheldon
I stream all my music these days, and I'm using Airport Expresses into my own DACs with asyncronous sample rate conversion. If I were doing what you would like to do, I'd use the I2S output to a sample rate converter chip (CS8421) and then to a good DAC chip and analog stage. I'd pay attention to the power supplies in the clock circuit of the ASRC and all the voltages in the DAC chip as well as the transmission of the clocks between the chips.
For a look at my DAC see: Sheldon’s World Blog Archive Another Audio Digital-to-Analog (DAC) is Born
Sheldon
A typical logic analyzer will tell you nothing about jitter. Right?
You will get more information if you ask some questions and stop making assertions. Most of your assertions so far have been inaccurate, and suffixing them with redundancies such as 'right' is just plain annoying. Right?
I'm sorry, it wasn't my intention to be annoying, I did not suffix my assertions with right redundantly, I did so because I was uncertain of them. I shall try to formulate my assertions more as questions from now on.
I started this topic out of curiosity about wether I could replace the WaveIO with a Raspberry Pi. The answers raised questions that obviously go over my head. I did not fully understand (and am still a bit unclear on) why the WaveIO would give a more precise signal when it gets its data over USB than the RPi would even if it itself was the source of the signal.
Since no one made final judgements on the RPi's amount of jitter I thought I could measure it and see for myself, but it seems that measuring it is also a hard thing to do.
Perhaps I should just buy them both and hear if there's a difference in sound quality.
Better to try and get to hear them side-by-side without buying them.
There have been lots of attempts to show how much jitter is audible. There's no doubt that as it gets worse, at some point it will become audible, but most USB DACs use a PLL based clock linked to the data frame rate, which is /millisecond. So the PLL has to interpolate 441 clock ticks per 10 data frames, an odd fraction and quite a high number. So this clock almost certainly has poorer jitter than the crystal clock in the computer by a not inconsiderable amount. Despite this, the evidence is that a Behringer UCA202 at $30 is barely distinguishable from the very best of DACs, and is perfectly enjoyable to listen to for most people in the majority of circumstances.
Take a look at the nwavguy's blind test, it will give you some perspective on the issue.
NwAvGuy: DAC Listening Challenge Results
Another person with a sensible approach to reproduction is Ethan Winer, who provides a number of online examples for people to educate themselves about the audibility or otherwise of various 'flaws' which are used to in a inverted sense to sell audio equipment.
Artifact Audibility Comparisons
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.