Nominally, the clocks are on the same frequency ( actually, an exact multiple for the read ). So even though the derived input clock may have jitter, the read clock is usually a MILSPEC crystal affair, on average you don't have any overruns or underruns.
Also the if the frequency of the read clock is much higher, then you don't really worry about the input clock jitter so long as it doesn't lose any data.
As the bits come in, they go into a barrel register and when the byte/word ( or sometimes a bunch of them as for long messages) is completed an interrupt is generated. The firmware picks up the interrupt and programs the DMA to transfer the data to DDR -if it's a big chunk of data. If it's just a simple one or two words, the data is simply copied over.
The real trick is how the firmware and hardware work together... and the resolution/accuracy of the read clock.
BUT, this kind of stuff is expensive... you see it in real time designs for avionics/routers... etc... but seldom in a commercial consumer product -except for current SoCs which are moving forward with ARM integration to complex systems heretofore unheard of. Many of the current SoCs use built in FPGAs as well as built in cores. Pretty neat stuff.
But those are mostly too expensive... the dev boards run at least $5K.
Maybe with a Raspberry and a hat...
... I tend to think you're really the hardware kind of guy, huh? The sort that I work with... most of them are into RTL nowadays... very few are still in the hardware "low level design" side of the house.
Remember the old saying: "We'll fix it in the software"... well, here we have been for a while... even stuff like DSPs now are just a "module" with a bunch of ioctl() registers and scatter/gather algorithms.
Last edited:
Why not? It is designed to be. The data is just shifted in the buffer to leave optimal headroom. Nothing lost, nothing gained.
Hi Bob,
unfortunately your thread,
https://www.diyaudio.com/community/threads/loudspeaker-relays.120365/
which you started 2008 is closed - therefore I have post some information concerning an interesting SDS relay for speaker protect under
https://www.diyaudio.com/community/...tant-rating-in-this-application.404480/page-2
check out posts #36 - #38
maybe of interest for you
unfortunately your thread,
https://www.diyaudio.com/community/threads/loudspeaker-relays.120365/
which you started 2008 is closed - therefore I have post some information concerning an interesting SDS relay for speaker protect under
https://www.diyaudio.com/community/...tant-rating-in-this-application.404480/page-2
check out posts #36 - #38
maybe of interest for you
If data is written into the buffer at a faster rate than read out (i.e. leading to buffer overrun) it is not possible to just shift the data to leave optimal headroom. Some data has to be discarded unless the reading rate can be adjusted to be faster (or writing made slower). If there is long enough passage of silence it may be possible to adjust discarded data to be just silence. But anyhow it is not exactly bit-perfect data stream anymore.
The thread is not permanently closed, old threads are now automatically closed after some time of inactivity, just REPORT the thread you want to reopen by clicking the "Report" button.
Last edited:
Consider the source of the data, as in a CD player. The clock frequency of the CD player that outputs its SPDIF can be slightly different than the clock frequency being used to clock data out of the buffer. Over a the playing time of an hour this can build up to a large number of bits. Even over the playing time of a long cut of 7 minutes or so, the number of excess or shortfall bits can be large. Some CD players have clocks more accuate than others (or closer to the frequency of the buffer readout in the DAC).
If the source clock and the readout clock differ by 50 ppm, at a 48 kHz clock rate, the frequency difference will be 2.4 Hz, meaning that one bit will be lost or gained every 417 ms. Over an hour of playing time, this amounts to 8633 bits. That is why some DACs employ an ASRC. Notable ASRCs include the AD1896, CS8421 and TI's SRC4392. These datasheets are a good read.
Cheers,
Bob
Cheers,
Bob
The point is it never waits until there is an overrun or underrun. Generally there is occasional silence, such as when clocks are switched, say, whenever the USB board MUTE signal is asserted. Then the buffer can be reset to mid midway before music starts playing again. In practice, mutes happen often enough that overruns or underruns are very rare. There is maybe a 1.5 second buffer that can be adjusted to longer or shorter as needed. That means it takes a very long time without a MUTE for an overrun or underrun to occur. In practice it just doesn't seem to happen in consumer audio playback. Maybe in other applications it would be more of an issue.
They are Acko Labs clocks. @acko is secretive about who makes them for him. https://sites.google.com/site/ackodac/modules-and-kits/clocks-and-oscillators
I would just add that is possible to get even lower phase noise starting with some Andrea Mori 5/6Mhz clocks followed by a couple of doublers.
Last edited:
Bob-
That would be a design errror.
In the aggregrate, the clock frequencies must be exact. But, they don't have to be in synch. Just so long as the buffer size is large enough to contain the results of the asynchronicity. And then, we can control the transmission of data to prevent over runs.
And, as a matter of fact, we do want the RX side to be bursty because transmission are more efficient when a bunch of data is prefaced by a single preamble.... the worst case is when you get a bus setup preamble for each datum.... Just look at the PCI protocols.. You're much better sending big chunks of data in one shot...
Case in point... downloading a video over ethernet with TCP/IP.. the download can be bursty but so long as the decoding is fed a nice, synchronous data stream all is well... The network can use back pressure to hold off the sender if it gets closed to a high water mark that determines the buffer is getting too full and on a low water mark -meaning the buffer is getting too empty- the network will tell the sender to send again..
Another case, the DAC's external interface should not be SPDIF.... but some kind of a bus interface with nice flow control. Ie: USB. Then DAC input is then separated from the wire transmission from the source to the decoding.
SPDIF between boxes is an old algorithm when you think about it. In the multimedia designs of current SoCs the media decoder block processes the SPDIF but it has been decoded by a module within the SoC. The external interfaces are byte/word based and the clocks are asynchronous.
Again, though, I think we're discussing somewhat different things. You are discussing how the hardware is going to handle the bitstream... I'm discussing how the hardware and firmware are gonna handle the bites/words that are constructed from the received data.
We firmware guys know about Manchester decoding but we never mess with it.
And at my level, the hardware doesn't deal with bit, but bytes... 32 bit words best!. We can use a network protocol to throttle the transmission of data. You, OTOH, are using asynchronous hardware that reacts to the transmission of voltage level changes in a data bus that eventually become bits...
UINT32, because who needs signed integers and floating point anyhow?
Last edited:
Well, now we have devolved into discussing things quite off topic. This discussion really deserves it's own thread, don't you think?
TonyEE,
CD players were designed long before external data transmission was even considered and we were stuck with internal subsystems the way they were designed. We can patch it, but that's it. Like the cassette tape format, we have done a pretty good job with what we were saddled with. It isn't a design error.
Y'know all ...
External DACs for CD's always detected and reconstructed the clock. As soon as you combine the three main data signals into a single stream, we are stuck with reconstructing it. SPDIF should have mandated the three signals, clock, LR clock and data on seperate connections. They didn't, although some proprietary interfaces did. They never caught on. The trick is to detect the clock from transmitted data (which is stable but the data isn't) and chase - lock to that. We discipline the DAC clock to that reconstructed signal, this eliminates the issues with dropping words and errors with the buffer over or under run. You still need the buffer.
USB is another thing again, data flow is controlled. However network streaming services use a SIP type transmission where the data is spewed, not error corrected of ever resent. Same as telephone or cell voice transmissions. It is up to the receiver to "fix it in the field".
By the way, "fix it in the field" is responsible for more problems. It is irresponsible and leads to poor quality firmware (or products in general). They started this with hardware causing nothing but service headaches and issues for end users. Cheaper for the manufacturer, but way more expensive for the industry. Windows being a perfect example. People who say "we'll fix it in the field" are idiots. They simply off-loaded their problems on end users and the economy.
TonyEE,
CD players were designed long before external data transmission was even considered and we were stuck with internal subsystems the way they were designed. We can patch it, but that's it. Like the cassette tape format, we have done a pretty good job with what we were saddled with. It isn't a design error.
Y'know all ...
External DACs for CD's always detected and reconstructed the clock. As soon as you combine the three main data signals into a single stream, we are stuck with reconstructing it. SPDIF should have mandated the three signals, clock, LR clock and data on seperate connections. They didn't, although some proprietary interfaces did. They never caught on. The trick is to detect the clock from transmitted data (which is stable but the data isn't) and chase - lock to that. We discipline the DAC clock to that reconstructed signal, this eliminates the issues with dropping words and errors with the buffer over or under run. You still need the buffer.
USB is another thing again, data flow is controlled. However network streaming services use a SIP type transmission where the data is spewed, not error corrected of ever resent. Same as telephone or cell voice transmissions. It is up to the receiver to "fix it in the field".
By the way, "fix it in the field" is responsible for more problems. It is irresponsible and leads to poor quality firmware (or products in general). They started this with hardware causing nothing but service headaches and issues for end users. Cheaper for the manufacturer, but way more expensive for the industry. Windows being a perfect example. People who say "we'll fix it in the field" are idiots. They simply off-loaded their problems on end users and the economy.
The clock phase and frequency are defined by ever digital "1" in the stream. This is way better than T1/E1 data that depends on a single sync bit every 192/256 bits. Modern serial data formats all use an embedded clock because separate clock and frame signals are inefficient and problematic.
https://en.wikipedia.org/wiki/Differential_Manchester_encoding
If the receiver has its own clock, it will use a PLL, probably digital PLL, to stay synced with the source. A digital PLL simply means, for example that the clock divider momentarily switches from /8 to /7 or /9 for phase correction. This means that one sample will last 26uS or 22uS instead of 24uS. Unless the clocks are way off and this happens constantly, no one notices.
https://en.wikipedia.org/wiki/Differential_Manchester_encoding
If the receiver has its own clock, it will use a PLL, probably digital PLL, to stay synced with the source. A digital PLL simply means, for example that the clock divider momentarily switches from /8 to /7 or /9 for phase correction. This means that one sample will last 26uS or 22uS instead of 24uS. Unless the clocks are way off and this happens constantly, no one notices.
Hi Steve,
You do not have a situation where you have regular pulses of any polarity to lock to. Even old colour TV signals had a burst that locked the 3.58 MHz sync of so many cycles (or clock sync) to in order to decode colour. It was detected using a filter (then they got fancier) because at least they had a frequency different from everything else to lock to in a specific portion of the waveform. I'd have to look up the specifics as I learned this when CD players were first introduced and they taught us absolutely everything. But one thing you do not have are regular data transitions at a set rate.
Separate clock and frame signals are inefficient - yes. They solved problems, they did not create them. The cable runs were short, so we aren't talking about long distance data transmission. This is one reason an internal DAC in a CD player has a leg up on an external DAC. If you are running "long" distances with three signals, you do run into issues with signal skew with less expensive cables. This is not the case with an external DAC as a rule.
You can't equate SPDIF with anything else really. Other serial streams use different encoding, you should see what's coming in USB with PAM4!
Anyway, this current discussion has nothing to do with Bob's new book. Let's respect the topic - please?
You do not have a situation where you have regular pulses of any polarity to lock to. Even old colour TV signals had a burst that locked the 3.58 MHz sync of so many cycles (or clock sync) to in order to decode colour. It was detected using a filter (then they got fancier) because at least they had a frequency different from everything else to lock to in a specific portion of the waveform. I'd have to look up the specifics as I learned this when CD players were first introduced and they taught us absolutely everything. But one thing you do not have are regular data transitions at a set rate.
Separate clock and frame signals are inefficient - yes. They solved problems, they did not create them. The cable runs were short, so we aren't talking about long distance data transmission. This is one reason an internal DAC in a CD player has a leg up on an external DAC. If you are running "long" distances with three signals, you do run into issues with signal skew with less expensive cables. This is not the case with an external DAC as a rule.
You can't equate SPDIF with anything else really. Other serial streams use different encoding, you should see what's coming in USB with PAM4!
Anyway, this current discussion has nothing to do with Bob's new book. Let's respect the topic - please?
As I said that means the data stream is not bit-perfect contray to your claim. Whether or not the scheme you described works with consumer audio playback depends on the difference between clocks. The larger the difference the sooner the buffer over/underrun occurs which may be well before any silence.
"Bit perfect" only exists in files transferred from a source that will resend information and has more robust error correction than a music CD has. Now if that source was information ripped from CD, it isn't "bit perfect". If you are using a streaming service, it isn't "bit perfect" either. That and a CD source is made to be in compliance (ie, valid data), but it sure is not "bit perfect".
I am getting tired of that phrase being used for any digital music file when it isn't true in many cases. The source would have to be from the original digital file the music was stored as (and not from old masters or a CD). A remix from the old beds would be maybe about as close as you could get if the original material wasn't digitized in the actual recording process.
I am getting tired of that phrase being used for any digital music file when it isn't true in many cases. The source would have to be from the original digital file the music was stored as (and not from old masters or a CD). A remix from the old beds would be maybe about as close as you could get if the original material wasn't digitized in the actual recording process.
I agree, "bit-perfect" is a poor choice of words in the end-to-end general sense.
In the case of a single function or piece of equipment it may be less objectionable. For example, perhaps a term like "non-bit altering" might be closer to what is being said. That might be OK in regard to something like dropping a bit or word here and there on occasion to make input and output frequencies the same on average, which might be considered as bit altering. However, when one gets into DSP functions, things like that tend to get blurred, with functions like interpolation and decimation, etc. It is easy to trip over semantics.
Cheers,
Bob
In the case of a single function or piece of equipment it may be less objectionable. For example, perhaps a term like "non-bit altering" might be closer to what is being said. That might be OK in regard to something like dropping a bit or word here and there on occasion to make input and output frequencies the same on average, which might be considered as bit altering. However, when one gets into DSP functions, things like that tend to get blurred, with functions like interpolation and decimation, etc. It is easy to trip over semantics.
Cheers,
Bob