The SPDIF interface is flawed so why even use it? Why doesn't the industry move beyond this. In the Feb. Stereophile there's a review of the Bryston DAC. The USB input of the $2,000 Bryston DAC only accepts up to 48KHZ sampling rate so the reviewer uses a Bel Canto SPDIF converter for the review and claims it's the best sound he's ever heard. Conveniently, he hasn't heard the favorite DACs of his colleagues at the publication. So Bryston get good press for making half a DAC. How pathetic!
A further note that I should have mentioned:
Where you really need galvanic isolation is on the in-coming USB connection so the dirty PC ground does not have a chance to feed through to the sensitive clock(s) & clock handling chips on the unit. This galvanic isolation isn't possible with the HiFace (& Musiland USB transport/DAC) as they use hi-speed USB 2.0 operating at 480Mbps.
Where you really need galvanic isolation is on the in-coming USB connection so the dirty PC ground does not have a chance to feed through to the sensitive clock(s) & clock handling chips on the unit. This galvanic isolation isn't possible with the HiFace (& Musiland USB transport/DAC) as they use hi-speed USB 2.0 operating at 480Mbps.
The S/PDIF interface is one of today's best interfaces for digital music, because it is streaming (non-package), and it can be optical too (i.e. via Toslink) which solves computer noise to DAC interference problems easily and effectively.
The S/PDIF interface is disliked by some, however what they really dislike is the sound from the inferior S/PDIF receiver solution at work, not S/PDIF itself.
If a good S/PDIF receiver is employed, S/PDIF is fully capable of the very best playback available today, including 192kHz playback of course.
Charles
That is a good idea.
You can of course send the clock, data and L/R signals via optical too, which would give you complete isolation.
However, after an optical transmission, you have to filter jitter again, that means you'd like to have a VCXO based PLL to recover your I2S signal with highest possible accuracy.
But then there would be no difference in using S/PDIF directly, except that with S/PDIF there's only one signal to be transmitted, not three as with I2S.
Yes, it is somehow a dilemma.
We want - we need- the digital signal to be completely isolated from the source's (computer) noise.
That definitely means optical.
But optical means at least a 'little bit' of jitter.
So we have to filter again, there's no way around.
But if we have to filter again anyway, we would like to use the best recovery available, that's via VCXO.
But then again, it would make no difference if we transmit S/PDIF or I2S, except that with S/PIDF we need to transmit only one line.
If both ways are realized perfectly, they both sound perfect.
Charles
It has been said before the galvanic isolation probably works best during an asynchronous transfer. Isn't the problem with SPDIF that it isn't asychronous transfer along with the fact that the clock has to be recovered from the data stream, which is affected by everything including the cable etc..
I still think there will be some good solutions forthcoming. There's a lot of good minds out there, though the best ideas are usually kept secret.
I still think there will be some good solutions forthcoming. There's a lot of good minds out there, though the best ideas are usually kept secret.
Yes, with S/PDIF the clock has to be recovered from the stream, but when the stream is good and if recovery is done via VCXO, you get a perfect result.
Isolating the USB transmission, with the USB-receiver being the clock-master, is a good idea at first glance, however it involves that your receiver needs to have quite a deal of computing power and associated noise itself.
Receiving a USB stream whether synchronously or asynchronously, and putting the packets back together and streaming them out, in fact needs some powerful computing /processing. The packet transfer generates jitter itself even if you are disconnected from the source's (computer) power noise, as it is not a continuous streaming transmisssion.
So you have jitter issues from the USB transfer itself and you have noise issues inside the USB receiving unit as it is a computer itself. You can of course power it by battery, but the generated noise will be the same. And the jitter caused by non-streaming packet transmission will be the same.
On the other hand, if you do a S/PDIF transmission via Toslink to a DAC with good VCXO based S/PDIF receiver:
The DAC will be disconnected from the computer power noise.
The DAC will be disconnected from the USB receiving unit's power noise.
The jitter generated by USB-package reception will be further filtered by the DACs VCXO.
The jitter generated by optical transmission will also be filtered by the DACs VCXO.
The DACs S/PDIF receiver only needs a couple of flip-flops and gates to do the job, and it runs in a streaming non-package operation, so it will generate less jitter and less noise itself, compared to a USB to I2S conversion.
This way a better conversion and analog output are possible.
This is not something to happen in the future, it is there already ... has been there for years.
Charles
The term 'asynchronous USB' seems to have become popular, IMO it is not really useful for describing what happens.
It actually means that the USB device is the clock master, not the clock slave.
In many older USB devices (i.e. m-audio USB-transit) the USB device was clock slave to the PC.
This means the actual audio clock was derived via PLL from the USB packets sent from the PC.
That was bad, a) because the PC clock was really not made for audio, in terms of stability,frequency and pitch center accuracy and b) you could not generate a high accuracy audio clock from USB packets, at least not by the means employed.
So the basic idea was that the USB device should have its own high quality audio clocks (being clock-master) and the PC should deliver data packets as slave to that clock.
The same way the M2tech hiface works, and funny enough, the USB-transit too, if it receives an external digital input.
You have the same situation with PCI audio cards. There are cards that are slave to the PC clock (bad) and there are cards with their own true audio clocks, thus being clock master (good).
However, even if a USB device is clock master, that does not mean that it has altogether no jitter. Jitter still happens as a function of the power supply and the current consumption. As USB data arrives in bursts, the current consumption will mirrow this, thus the supply voltage too, and this directly translates into jitter.
It is of course much much better than a USB device working as clock slave ...
The S/PDIF signal on the other hand is continuous. That means continuous power consumption, no variations of supply voltage, less jitter. So it has the potential of the very best playback quality, if implemented correctly.
Charles
I see it the other way round:
I2S is even older than S/PDIF
S/PDIF will still deliver superior fidelity, after USB and firewire have long been removed from our computers.
S/PDIF was especially designed for audio and has highly desirable properties, as laid out above.
The reason that some do not like S/PDiF is invariably due to bad implementations, and yes, we had a lot of those, LOL
Charles
The ways of S/PDIF?
Conversely, what makes for a good implementation? You've mentioned the VXCO recovery, but what would be the other Must Do's to get the best S/PDIF performance?
Cheers
Okay, I'll bite; what are the hallmarks of a bad implementation -- those cardinal sins you spot.S/PDIF was especially designed for audio and has highly desirable properties, as laid out above.
The reason that some do not like S/PDiF is invariably due to bad implementations, and yes, we had a lot of those, LOL
Charles
Conversely, what makes for a good implementation? You've mentioned the VXCO recovery, but what would be the other Must Do's to get the best S/PDIF performance?
Cheers
Okay, I'll bite; what are the hallmarks of a bad implementation -- those cardinal sins you spot.
Conversely, what makes for a good implementation? You've mentioned the VXCO recovery, but what would be the other Must Do's to get the best S/PDIF performance?
Cheers
It's exaclty as you say, the most important factor when recovering clock and data from S/PDIF, is that you do not do it with a VCO based PLL as used in 99.99% of all S/PDIF receiver solutions at work, i.e. Crystal/Cirrus 8212/8414/8422, Burr-Brown (Texas Instruments) DIR9001, AKM AK4117, etc.
A VCO has a wide locking range and is cheap, only some external RC required. The upside is the downside. The wide locking range makes it not so good at filtering incoming jitter, especially when it comes to lower frequency jitter.
A VCXO on the other hand has a very narrow locking range, typically only +-100 or +-150 ppm. It's frequency can only change that much. The downside here is that you need a transport that plays on accurate pitch. This is not a problem with 99% of all transports, CD/DVD players out there, or when you use the M2tech hiface or the ESI Juli@ PCI card, as these products have true audio-clocks on board.
However it can be a problem when you use a USB to S/PDIF device or soundcard, which is not clock master (what some call asynchronous), but clock slave to the PC (i.e. Hagerman, or m-audio USB-transit).
Depending on the PC's clock, the S/PDIF stream can then be too far off center pitch. That means the source will not play 44.1 kHz but 44.2 kHz, out of the pulling range of the VCXO -> no music.
Another downside of the VCXO is its price, it is much more expensive compared to a VCO, because the VCXO is a precision oscillator. And you need 2 of them, one for sample-rate 44.1 and its multiples 88.2 and 176.4 and the second for sample rate 48 and its multiples 96 and 192kHz.
But performance-wise the VCXO is very hard to beat. The final performance depends on the quality of your VCXO, on the power supply purity and the design of the phase comparator and loop filter.
There are 2 ways of incorporating the VCXO into the S/PDIF receiver solution. a) you program your own receiver chip, like I did for my Attraction DAC. b) you use a ready made receiver chip, and build a 2 stage PLL. First stage is the reciever with its VCO -> still lots of jitter, but clock and data are already separated, and then you feed the clock into the 2nd stage which is VCXO based. This will give you a pure clock now, and you just have to recover data and L/R using flip-flops running on your pure clock.
I can understand that some became frustrated about S/PDIF, but it is really due to the cheap receiver solutions.
The S/PDIF format itself has great potential and functionality.
Oops, long post, LOL :0)
Charles
External sync definitely works with the USB-transit. It is implemented automatically. As soon as you insert a Toslink connector to the input, there will be sync to the external clock. There is a contact switch inside, so the switches to slave-clock, else the PC is clock master.
I came first to know 5 years ago when I called m-audio tech support, as my transit was not working. The Techie asked if I had connected something to its input, I said yes, but only an Toslink mini adapter, without the cable, then he told me about the switch, that is activated upon insertion, and then chose external sync.
Charles
Hi Charles!
Are sure about this? My Transit surely doesn't work that way. Later you are still saying:
Do you happen to know which revision you have?Charles said:
Exactly, there may be less jitter without the S/PDIF interface at all, compared to using S/PDIF with an inferior S/PDIF receiver.
Charles
Absolutely, you just try and you will see within 5 minutes.
No need to double ask
The m-audio USB-transit is a special case. It works as clock slave to the PC-clock (not so good) when no digital input is connected to the device.
It works as clock master to the PC (good), as soon as an active digital input is connected. Just connect your CD's digital output to the input of the transit, and the digital output of your transit to your DAC.
The clock from your CD player will now be clock master to the audio stream, that the transit receives from the PC.
Very simple ...
Charles
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.