Network-to-SPDIF (e.g. Airport Express) or why network jitter should matter?

[jesk]

Hi,

I'am trying to understand why everywhere the issue with audio-source-to-SPDIF conversion is so much sensitive discussed when it comes to quality. Its always mentioned that jitter sensitivity lies in the picosecond area! Comparing this latency with common network latency in the typical homeuser network, which lies around 0.2-3 milliseconds when wires are used or 0.5-5 milliseconds if a good wireless network is used, I'am wondering how much truth lies in that, as 1 second is 1.000 milliseconds and 1 millisecond is 1.000.000.000 picoseconds (what the hell!).

When thinking about digital streaming I'am thinking about sending audio (PCM or whatever) as RTP (real-time transport protocol) over the network to the RTP stream-receiver or playback device (eg. Apple Airport Express). Other possibilities are mounting filesystems over the network like NFS or SMB and reading the audio data with filesystem operations (opening files over network and reading them). In my understand it should be unimportant which kind of mechanism is used as all the audio data should be cached in the playback device for a small amount of time - so in case of RTP the packets are reordered first and then cached for final playback - and after the caching interval (time or data amount) the sampling of the data to SPDIF-out should begin.

Using that basic principle the way network streaming works why should network latency (when no buffer/cache underrun happens) influence the quality of the SPDIF-out sampling at all? Shouldn't be the only mattering parameter the SPDIF-to-SPDIF jitter (e.g. networkplayer-to-AVRorDAC)? Shouldn't that jitter be deduced from the network side to the SPDIF side?

 

[Welwynnick]

Steve Nugent of Empirical Audio really knows his stuff on this subject. Have a look.

Nick

 

[jesk]

Ok I did. This explanation is only about the last-mile so like SPDIF-to-SPDIF where the DAC lies. Its not about the other side - the network side. I think that this part shouldnt matter at all. Maybe some people just missunderstand this.

 

[Autopilot]

Network jitter and jitter you refer to on SPDIF are very different things. Its confusing for some people because there are lots of cases where word 'jitter' is used but means something different. There is nothing on Network side that can effect sound quality in any way, so you will need to rule that out of your thinking.

 

[jesk]

One moment, I dont think that its that easy.

In a packet network you normally have on the receiving site when RTP is used a RTP receiver which has in front of its engine a packet buffer. This buffer fills up and no exact timing of sending data to the receiver is needed. This buffer should be large enough that even large difference in clocking on both sites can be absorbed. When the sender sends faster then the receiver can decode the buffer fills up. This is happening really slowly, because the clocking never differs that much. Is the receiver decoding faster the data in the buffer will be used until its empty. That way - I believe - clocking problems could/are avoided.

When it comes to SPDIF I'am not aware of used buffers. So is that the only difference why SPDIF is more critical? If, why are there no buffers?

 

[Autopilot]

I think you need to go back here a bit and learn a bit more about these technologies. Network and SPDIF work very differently. They are not comparable in this sense. SPDIF sends a clocked bitstream to a DAC, in real time if you like, which can be effected by jitter. A network transmits data packets, there is no timing to go wrong as such its not time critical. Jitter does not exist at this stage, the audio has not been decoded and passed to the transport.

God, Im doing a terrible job of explaining this. Maybe someone else could do it better.

 

[jesk]

RTP data so IP packets full of the original audio is also multiplexed into the network in real time. Just the used buffer on the receiver takes care of not 100% in synch working clocks. RTP is for streaming, most times used in todays world for voice over IP. You are right when you talk about mounting filesystems over network file protocols like SMB or NFS. These use TCP rather than UDP and the receiver is acknowleding the received data. When it has enough and the buffer is full it wont acknowledge anymore and the sender throttles down. This is not real-time. But the important thing in both techniques is that a buffer is in used.

Some devices use uPnP with or without DLNA (uPnP castrate) which streams via RTP/UDP. Others like iTunes with Apple Airport Express uses RTP directly. So again realtime transport as the name says (real-time transport protocol). SMB or NFS so TCP is used by others, often seen in mediaplayers.

Where is the buffer in the audio world where e.g. SPDIF is in place. This would solve the problem in my opinion.

 

[Andy8421]

Jesk,

There are a few DACS that use the technique you describe to de-jitter the S/PDIF bitstream. The S/PDIF data gets read into a buffer using the derived S/PDIF clock, and gets read out using a local clean low jitter clock. Various techniques for avoiding buffer over/under run have been mooted, I cant remember which is most common. There is certainly one that 'chooses' the closest frequency ultra stable local clock, then sticks with that for the session. There is another which has a variable clean local clock that is driven PLL style to run at the average rate of the input clock.

As you point out, this is not new technology. If widely implemented, it would put the S/PDIF jitter story to bed. I sort of recall that an ASIC manufacturer has announced an S/PDIF interface IC that does exactly this.

Edit: Found a white paper about the IC in question. From Wolfson.

http://wolfsonmicro.com/uploads/documents/en/A high performance SPDIF receiver_Oct 2006.pdf

Andy.

 

[jesk]

I have to read more about current SPDIF implementations from different vendors.

I think that its also a wide missunderstanding that SPDIF, HDMI etc. are different from IP networks. They are not. Both have to deal with transporting in real-time. Usage of real-time is just not that much needed in todays IP networks. Voice over IP, Video conferencing etc. are cases where it is. The problems of real-time transport are solved with buffers. Otherwise its not 100% solveable. SPDIF is same story. Nothing different.

 

[Andy8421]

Jesk,

I am not sure about the misunderstanding you refer to. I think most people who design interfaces understand it. If you a referring to the hifi and AV press, as far as I can tell, they dont understand anything - so you could be right.

S/PDIF is an old cheapo standard, full of limitations. As you say, a buffer / reclock approach gets rid of the jitter issue, but without some sort of flow control you end up needing to run the output clock at the same average rate as the input clock or you get buffer over/under run. This makes purists wince, as the the output clock is still a function of the input clock.

A nice modern standard with flow control would be far better. USB seems the obvious choice. I dont understand why the industry doesn't just agree to ditch S/PDIF and use USB instead.

Andy.