why some DACs not syncing with hires?

Are you sure the DACs support 96/24?  The DAC should sync to the S/PDIF bitstream output and extract the timing from the source, i.e. the clock in the NDX is controlling the timing.

Oh, I was actually not inquiring about syncing of clocks, but about the locking of the DAC to the incoming sample rate.

The DAC decodes the clock information from the incoming signal, but does this mean all DACs should be able to lock to any sample rate, even if it is not their 'standard' PCM sample rate?

Simon - I think you're referring to a modern asynchronous DAC that is buffered and has two separate clocks.

Noogle

Yes there are two things happening - the trasnport data stream and the sample stream. Both need managing.

DACs have always had to have thier own clocks, though in the early days I use to use cheap little crystal ocillators to drive a latched parallel data bus, but 16kHz and 8 bit it didn't matter

However early implementations (either implemented in the chip itself or off chip) had a small buffer that was clocked in. Becasue this buffer was small the DAC clock had to be constantly adjusted via the PLL or similar. This caused jitter in the sample in the DAC clock.

As buffers have got bigger ans strategies have improved for managing differencies between source and and sink data rates (as opposed to sample rates - as that is set at the time of original encoding) then the the amount of adjustment of the master DAC clock has decreased, and therefore induced jitter/wander has decreased.

So in summary there are two clocks with a DAC withan SPDIF input

1) Transport clock - this is extracted from the rising and sinking edges of the SPDIF data stream. This can be quite jittery in practice due to driver quality, interface quality and electrical cable with reflections etc. However a PLL can be used filter this out, a bit like the spinning tape head of an old VHS video recorder.

2) The DAC clock. This is the clock that is essential to the reconstituion of the analgue signal. Any jitter here is audible.

The aim isto keep 1) and 2) as seperate as possible - but in the real world there are electrical / EMI inter effects as well as clearly wander.

Simon

DACs have a number of set operating sample-rate/bit depth combinations e.g. 44.1kHz/16-bit, 96kHz/24-bit etc.  The PLL will lock for a range of bit rates around the central frequency to allow for some tolerance in the source clock.  If the source clock is outside this window the DAC won't sync.

I had an old PC once that wouldn't sync with my DAC because the source frequency was out of whack (cheap oscillator on the PC).  Fitting a Musical Fidelity V-Link (accurate clock) fixed this.

Noogle, no you still appear to be confusing transport and sample clock...

The sample frequency is carried in the SPDIF header. The PLL can't look for anything,it is an algorithm that simply adjusts a clock on the phase errors between input and output.

If the ratio of the sending datarate to the trasnportd data sample rate is incorrect or there is some other error, then clearly the audio can not be reconstituted in real time - as you woul have to slow or speed up time! Therefore the the master DAC clock is / or can beadjusted to keep the transport buffer (whether old and small or modern) in an optimum position.

Now if this error betweentrasnport and sample of a prticualr period of time was significant - then yes the reciever would have no ooption but to discard the signal. Also if the transport clock is too jittery the receiver might not be able to keep up with the changes, and keep trying to reset.

Simon

The sample frequency is carried in the SPDIF header.

My bad... This is incorrect. The receiving implementation recovers the intended data rate from the transmitted data frames containing the 32bit words. So Noogle you are correct, the receiver looks at the overall data rate and uses a strategy to chose which bucket to best put the receiver sample data rate to. So if can't see a valid bucket - it will discard it.

But i trust you can see how the transport clocks and sample clocks are seperate?

Simon

Sure.  Interesting issue is why the NDX isn't syncing with Aysil's DACs.  The NDX should have a super-accurate clock which is well within the DACs' PLL acquisition window.

simple! I just found out the DAC in question uses a NOS 18bit chip, so can not handle 24 bit-depth. Those DACs which use 24bit chips seem to be handling hires files.

Aysil

You might have found it, SPDIF can support 16bit, 20bit through 24 bit (although 24bit is optional). The spec  states that only the most significant bits are used with the rest being zero.

Interestingly in looking at the standard further I see stricty IEC958 Consumer superceded SPDIF, and indeed IEC958 supports BNC connections on the interface (unlike SPDIF).

Noogle

The area that intriques me is the Control channel information in the SPDIF (IEC958) protocol. There are two variants - Consumer and Professional. This is the difference between AES3 and SPDIF.

Now I can see all sorts of potential issues for interoperability (I thought sample rate was defined in the Consuer control word - and indeed it is)

So in the  consumer  control channel within SPDIF we see the following:

Things to note here are I understand some DACs - certainly in a professional envionment can reject Class 0 - ie consumer. and also if using Class 0 formally Fs upto 48kHz is only supported (bits 24 and 25)/ Therefore if using a higher Fs  - where the receiving DAC reads the data rate and estimates the best bucket - this strictly is not supported at SPDIF - but is at AES3. Therefore I can see potential interoperability issues between data rate and what was sent in bits24 and 25 in the control channel.

I do wonder if this what is happneing with some of the strange outputs from NDX to thirdparty DACs.

I did ask Naim via Richard, what bits Naim uses in the Control Channel so as to make clear. But I stillhave no update.

Therefore if sending anything above 48kHz on SPDIF I would certainly cehck first for interoperability. (It could be one reason why Apple limit thier IEC958 Conssumer interface to 48kHz - becasue that is all that is officially supported.

I am looking for an addendum to IEC958 that addresses this matter for interoperability but I have not found one yet.

Simon