Simple Streamer with 192/24 SPDIF output?

UPnP, Ethernet and Jitter...

Surely the whole point about using UPnP is that it avoids the **effects** of jitter in Ethernet because you are not passing digital data you are passing an encoded file. What is sent to the streamer is FLAC or ALAC or WAV, etc. not SPDIF time critical data.

The "streamer" then has sufficient data to (in all but the worst cases) reconstitute the data and decode it in time for the DAC to convert it to analogue.

So yes there is jitter in Ethernet - it's digital transmission so it's inevitable - but the jitter there is irrelevant. Or am I completely wrong?

Eloise

quote:

ROTF,

I´m sorry, I have to disappoint you, I´m working in IT for almost 20 years and dealt with many companies. That´s where I have my experiences from. But there is a hugh difference if you have an Apple workstation for €10k or an iRubbish. Apple has created almost a monopoly with iTunes and this for me is not acceptable, but offtopic.

Dear Yeti

No need to apologise I'm not disappointed just surprised. You're entitled to your view, of course. Are you in sales per chance? I'm not in sales; my job used to be to help improve the quality of software: some companies react positively if you demonstrate a flaw in product, whereas others react differently - IME Apple are very positive and never threatening. Your view of Apple is very strange though; it is a shame your experience with them was not good, as it is very different from mine. Still we should learn to move on.

I didn't mention S/PDIF jitter - simply pointed out the problems with Ethernet (it is an old technology, but has become a de facto standard). I guess the way electricity comes to my home is old fashioned, but I still use it and live with its limitations - so being old does not equate with not being useful.

Anyway, I hope Naim makes the NDX for you - it is not a product for me as I prefer a dedicated DAC and the box count doesn't worry me. I may buy a UnitiServe or I may not; I would have to like it much more than my Apple front-end to change.

ATB Rotf

quote:

Originally posted by yeti.fro:
Apple has created almost a monopoly with iTunes and this for me is not acceptable, but offtopic.

In some ways this is undeniable, but Apple have created the large market that they have by providing a good product. I'm unsure if you are also criticising Microsoft and others, but this is totally different kind of monopoly - don't forget the scanalous business practices of Microsoft in forcing all computers a company sold having a copy of a MS operating system, regardless of if the OS was needed. Okay, so iTunes is a bloted, confused piece of software in dire need of a rewrite, but you have pleanty of alternatives if you don't like it ... that rather means iTunes isn't a monopoly as everything iTunes can do can be done elsewhere (except for Audible and pre-2006 DRM'd downloads I accept).

Yes Apple protects their patents, why shouldn't they. They are also going after companies who exploit their software to sell their own products (Psystar), but to say they should sell Mac OS X separate from an Apple computer is like saying Naim should have to sell the HDX software separate - lets face it to all intents and purposes the HDX is a PC.

Eloise

quote:

Originally posted by Eloise:
So yes there is jitter in Ethernet - it's digital transmission so it's inevitable - but the jitter there is irrelevant. Or am I completely wrong?

You are certainly right. As far as I understand, every streamer needs to have buffers (RAM) for receiving ethernet frames, extracting the data and reassembling the music file (UPnP is a conventional TCP/IP protocol after all). The streamer can then clock the data into the dac from its RAM buffers using its own clock. In principle, if buffers were large enough, a streamer could buffer the whole piece of music before starting to play, without any jitter from the ethernet stages remaining in the buffers. The only problem is when the buffers deplete because of network outage or other problems. Then you get spinning sand clocks etc.

It's the same prinicple as with the Naim DAC and its RAM buffers, only with Ethernet frames instead of SPDIF frames.

This is different from VoIP e.g.. In VoIP, buffering does not help very far, because when you buffer for more than some milliseconds you get noticeable delay/latency in the conversation and both parties start talking at the same time. This is why you need low network jitter in VoIP networks.

quote:

and even in this case the overall jitter of KDS is bigger than the jitter of Uniti playing CD or a jitter of other well known cd players. Funny isn't it?

Ferenc

Just for info what are the quoted jitter rates of the KDS and the Uniti. I haven't seen a spec for the KDS or ADS.

Also is this over and above the jitter resulting from the ripping process at the other end of the wire?

regards
Geoff

Hi Geoff,

this what you can find in Stereophile regarding KDS jitter:

"When the Klimax DS was fed a 24-bit version of the Miller/Dunn J-Test tone and tested with the Miller Audio Research Jitter Analyser, a pair of sidebands appeared at ±1.5kHz, with a total jitter level of 200 picoseconds peak–peak."



Stereophile measurement of Uniti:

"Any jitter-related spuriae with CD playback was below the threshold of the Miller Jitter Analyzer; however, I did measure 78 picoseconds peak–peak when the same J-Test signal was played back from a USB drive, this rising to 236ps p–p for iPod playback, and to 454ps p–p for an external TosLink datastream."



This is another example of a network player, not UPnP however, the wellknown Transporter, from Stereophile too:

"Fed 24-bit data via the WiFi network, the Transporter developed just 235 picoseconds peak–peak of jitter with no data-related components. Decreasing the word length to 16 bits gave the spectrum shown in fig.10. Here the jitter level has increased slightly, to 268ps p–p.... Repeating the measurement with 16-bit data fed to the Transporter via an optical TosLink S/PDIF connection increased the jitter to 313ps p–p"

Thanks ferenc

I wonder what the jitter is like at higher frequency (96 & 192). Did they mention if the CD on the uniti was 16 or 24 bit.

regards
Geoff

So, a Uniti has unmeasurably low jitter when playing a cd, yet 454ps p-p jitter when playing another source via s/pdif. Similarly, driving a a Transporter via s/pdif increases the jitter.

So, indubitably, s/pdif can introduce a serious amount of jitter, as the DAC in the Uniti (or Transporter) is at the mercy of the clock in the datastream being fed to it.

But there is no embedded clock signal in a network packet, so it simply cannot suffer from jitter in the same sense; any measured jitter is solely a function of the DAC, not the source. Just because Linn can only manage 200ps doesn't mean that NAIM couldn't do a lot better.

Indeed one way of looking at the design of the Naim DAC is that it kind of turns an s/pdif data stream into a pure, dare i say network-like, data stream by buffering it and not using the clock signal in the s/pdif, except at a gross level to pick the correct (low-jitter) clock of it's own.

quote:

Originally posted by likesmusic:
Indeed one way of looking at the design of the Naim DAC is that it kind of turns an s/pdif data stream into a pure, dare i say network-like, data stream by buffering it and not using the clock signal in the s/pdif, except at a gross level to pick the correct (low-jitter) clock of it's own.

The linn runs off its own clock with network data in a simlar way so don't expect a massive improvement compared to that

Isn't the point that me and others are trying to make that a network DAC, like the Linn DS, is entirely dependant on the quality of it's own clock, whereas most DACs driven from an s/pdif source are dependant, to varying degrees, on the quality of the clock in the s/pdif signal, which is invariably and unavoidably degraded. This is the reason naim have avoided making such a DAC until recently, and they reclock the data completely as it comes out of the buffer. No clock is perfect, so there has to be some jitter, but s/pdif can only add jitter, whereas networks cannot. You can email a WAV file to someone a million times and there will be no more jitter in the millionth copy than the first - it is just not an applicable concept. The sample rate is in the file header; end of story. Right click and check the audio properties!

OH...OK

quote:

Originally posted by likesmusic:
but s/pdif can only add jitter, whereas networks cannot. You can email a WAV file to someone a million times ...

Ethernet networks have jitter too, look at VoIP. Buffers help to eliminate jitter from the previous stages, however at the cost of increased latency. SPDIF and Ethernet networks are not different in that respect.

If the buffer is large enough to hold the entire file (i.e. when you receive an e-mail and save it to local disk or file system cache (RAM)), there is no jitter left from the previous network transport, that is correct. Which means: only the content of the file is saved of course, we forget the individual arrival dates of the individual data packets. Any further transport or processing then potentially adds its own jitter.

likesmusic:

if you would like to think, UPnP is just like sending wav files in an email, I am not here to convince you it is not. We do not agree how it works, but do not want to waste other's time with repeating myself.

However if I follow your way of thinking, than I easily can reach the conclusion, Naim did absolutely fantastic job with the clock and D/A system of Unity. According to your way of thinking, as UPnP is a jitterfree transmission format, all the roughly 200ps jitter of KDS is generated by the internal buffering and clock system and the D/A conversion itself.

So when Stereophile measures 78 ps jitter of Uniti playing from an USB memory it means, Uniti's clock and D/A conversion adds roughly one third of jitter of the KDS to its D/A process. It is good to see that even an iPod caused jitter can be on par with the KDS and UPnP in case of Uniti.

I am sure it is a fantastic news for a lot of potential and existing Uniti customers Even better news for the nDac customers, where the USB reading is more sophisticated and the buffering, clocking could be even much better than a Uniti.

I am exaggarating a little bit of course, but this measurement comparison shows how false and misleading can be to study only the measurements and technology.

Stereophile's measurement of Toslink jitter is not representative as SPDIF, you can handle it as a kind of worst case only. SPDIF coax certainly can be much better, around the same 200 ps or even less, than the jitter of KDS. It is just question of optimized design.

Jitter values are completely meaningless at this 2-3 hundred picoseconds level, there is no way to get useful practical conclusion how differently a REPRODUCTION SYSTEM will sound in case of two slightly different values. A competent design team can design equally good DAC through any of the available transmission methods, it is just about optimizing its design for the chosen transport technology and source - DAC connectivity.

ferenc, I just used email as an analogy. You can equally send some music via upnp a million times and not a picosecond of jitter will be added, for it cannot be. jitter is a concept that applies to a clock signal. Where is the clock signal in a upnp packet?

Of course it is all about design; in my view the RAM buffer that precede the DAC in the the Naim DAC is just crying out to be filled via upnp or some network protocol .. I bet if you were to go through the secret trapdoor in Salisbury you'd find just such a device on some young engineers bench ...

quote:

I just used email as an analogy.

How about another analogy - in the oldern days, we connected a line printer to our computer via parallel (or serial) connection. Each character to be printed was sent one at a time, the printer head moved across the line at a fixed rate and if the computer was interrupted in sending, a character could be missed or incorrect character printed (and yes this happened - I've seen it).

This is analogous to SPDIF (as far as it goes) - the signal quality can be affected by delays (jitter) in the digital signal.

Modern printers work by having a huge buffer. A description of the page to be printed is sent and the computer inside the printer reconstitutes the description into a graphical output which the printer recreates on the page. If there is a delay in transmission, the printer waits until the data is received.

This is analogous to IP / UPnP transmission of audio - the signal may drop out because the buffer is empty, but the signal quality is never degraded because of delays (jitter) on the digital (Ethernet) signal.

quote:

Of course it is all about design; in my view the RAM buffer that precede the DAC in the the Naim DAC is just crying out to be filled via upnp or some network protocol .. I bet if you were to go through the secret trapdoor in Salisbury you'd find just such a device on some young engineers bench ...

Maybe some as yet unknown network protocol - something like Resolution Audio's Pont Neuf ... but I really don't think UPnP is the answer - though Linn and PS Audio would disagree I know.

Eloise

quote:

Jitter values are completely meaningless at this 2-3 hundred picoseconds level, there is no way to get useful practical conclusion how differently a REPRODUCTION SYSTEM will sound in case of two slightly different values. A competent design team can design equally good DAC through any of the available transmission methods, it is just about optimizing its design for the chosen transport technology and source - DAC connectivity.

I will let you guys and gal continue your inetersting to read discussion of the realative merits of transportation systems. For me ferenc's statment above sums up where I am coming from. I can read the 'selling blurb' on both Naim & Linn's web sites. Both explain how hard they strived to provide the very best result. Linn for example talks of building numerous DAC boards to test individual DAC ICs before settling on the Wolfson chip as the one they liked best. It hardly seems likely that having found the baby they would throw it out with the bath water by skimping on the design of the support circuit to buffer, reclock and upsample.

In the end it is what my ears tell me sitting in front of my system that makes the choice.

regards
Geoff

quote:

Originally posted by Geoff P:
In the end it is what my ears tell me sitting in front of my system that makes the choice.

Right on Geoff ...

To everyone... remember...

• There are many ways to listen to music.
  
• Naim won't produce devices for EVERY way.
  
• Not every device will suit every person.
  
• Naim will produce devices which both sound great, and also are commercially viable.

Eloise

quote:

Originally posted by Eloise:
How about another analogy - in the oldern days, we connected a line printer to our computer via parallel (or serial) connection. Each character to be printed was sent one at a time, the printer head moved across the line at a fixed rate and if the computer was interrupted in sending, a character could be missed or incorrect character printed (and yes this happened - I've seen it).
Eloise

Good analogy. If nobody minds, I have another:

You are member of a fire brigade, there is a fire alarm and the fire hose is broken. The fire brigade has to make a bucket chain: Every person can hold exactly one bucket of water and passes it to his/her neighbour.

You are somewhere in the chain. However, for some reason the fire chief approaches you and says: "The flow is too unsteady, you are now responsible for delivering at a steady rate of 1 bucket every 5 seconds. Don't drop a bucket and keep them in the numbered order".

What can you do? If you released your bucket and the preceeding chain is late, you can't deliver the next bucket in time, because you don't have one. OTOH if you still have your bucket and the preceeding chain is early, you have to release your bucket ahead of time, unless you drop the arriving bucket.

But Chief said nothing about latency, so you wait for e.g. 10 bucket times and start building a queue of buckets before your feet. When the queue is full, you start delivering at the specified rate and Chief is happy.

So buffering helps to remove jitter.

KR
Jochen

quote:

Originally posted by Geoff P:

quote:

Jitter values are completely meaningless at this 2-3 hundred picoseconds level, there is no way to get useful practical conclusion how differently a REPRODUCTION SYSTEM will sound in case of two slightly different values. A competent design team can design equally good DAC through any of the available transmission methods, it is just about optimizing its design for the chosen transport technology and source - DAC connectivity.

I will let you guys and gal continue your inetersting to read discussion of the realative merits of transportation systems. For me ferenc's statment above sums up where I am coming from. I can read the 'selling blurb' on both Naim & Linn's web sites. Both explain how hard they strived to provide the very best result. Linn for example talks of building numerous DAC boards to test individual DAC ICs before settling on the Wolfson chip as the one they liked best. It hardly seems likely that having found the baby they would throw it out with the bath water by skimping on the design of the support circuit to buffer, reclock and upsample.

In the end it is what my ears tell me sitting in front of my system that makes the choice.

regards
Geoff

If the way of the connection between source and DAC would be so much important as few would like to see in the case of a competently designed, similarly priced high-end digital products, than it would make our life much easier. But unfortunately this is not the case. The whole is always important than the parts.

So it is quite funny to see on some other forums where users of different DSs are discussing how much difference a cat6 cable or a newer gigabit switch can make...

Naim have written their own UPnP server softare.

Naim have just released two variants of the UnitiServe - UPnP server/ripper hardware designed to connect to a network.

Naim have updated the HDX, including the ability to access music stored on network drives.

Naim and Naimnet have masses of expertise in networked audio, and an increasing porfolio of networked products.

Yet the DAC, at the moment, does not connect to a network.

Anyone smell the coffee?

quote:

Originally posted by likesmusic:
Naim have written their own UPnP server softare.

Naim have just released two variants of the UnitiServe - UPnP server/ripper hardware designed to connect to a network.

Naim have updated the HDX, including the ability to access music stored on network drives.

Naim and Naimnet have masses of expertise in networked audio, and an increasing porfolio of networked products.

Yet the DAC, at the moment, does not connect to a network.

Anyone smell the coffee?

They think the computer device should be separate from the DAC is the only conclusion that can be drawn there. Maybe as a result of developing HDX and the Uniti products they have concluded for best performance this separation should occur?

If you think of time line ... HDX then a separate DAC and Streamer (UnitiServe). The two parts are diverging not converging!

Eloise

and the coffee's good. Naim doesn't have an issue with SPdif as configured in the DAC and the HDX could always access stored music on a network drive. The resulting jitter # is lower than those quoted by ferenc for those all in one streamers. That Naim accomidates network and upnp doesn't mean it needs to be in a DAC. It's about access to music. It's also not in any of the DACs that are though to compete with it on a price, performance ratio either.

Why all the angst? If you can't get the features you want at a price you need, just look elsewhere.

quote:

Originally posted by likesmusic:
Naim have written their own UPnP server softare.

Naim have just released two variants of the UnitiServe - UPnP server/ripper hardware designed to connect to a network.

Naim have updated the HDX, including the ability to access music stored on network drives.

Naim and Naimnet have masses of expertise in networked audio, and an increasing porfolio of networked products.

Yet the DAC, at the moment, does not connect to a network.

Anyone smell the coffee?

Yes, my afternoon Goppion CSC espresso just smells right and inviting right out of the Gaggia.

I hope Naim leave the DAC as it is, a DAC, give me freedom to use source(s) I want to use, like USB memory, which is even more perfect, " 3 times better" then the network, as we just learned from the Uniti measurement.

I am extremely happy with Hiface EVO/PH PS as well and nDAC/XPS2, with the USB reading capability of the nDAC. It is just perfect for my taste and covers all the sources I need.

quote:

Originally posted by Eloise:
They think the computer device should be separate from the DAC is the only conclusion that can be drawn there.
Eloise

As indeed it still would be if the DAC could be connected to your network. The 'computer device' - be it a UnitiServe, HDX or your own pc - would still be somewhere else on your network.

Coffee time!

quote:

Originally posted by likesmusic:

quote:

Originally posted by Eloise:
They think the computer device should be separate from the DAC is the only conclusion that can be drawn there.

As indeed it still would be if the DAC could be connected to your network. The 'computer device' - be it a UnitiServe, HDX or your own pc - would still be somewhere else on your network.

I know this is said repeatedly, but to have a UPnP streamer IS to have a computer device. It's not a general purpose computer but it's still a computer. To have the computer elsewhere on the network would require a completely new set of Ethernet protocols which (as far as I am aware) don't exist.

Don't think a streamer is NOT a computer. If you add (any of the common) form of Ethernet input to a DAC, then you are adding a computer to it - it's just not a general purpose computer.

Eloise