Which sounds better streaming or dig out?

quote:

Originally posted by AMA:

quote:

AMA, Top kit has always gone to more seperated.

js this

genelec, Eww.

I've got no problem with a different approaches to streaming but when combining, where do you stop and should a upnp source be arbitrary? There's always trade offs of specialization vs integration and it's often difficult to be sure where that line is. History points to specialization but execution still trumps all.

Only grumpy when woken up by marauding cats... The woods can be a dangerous place ..

Sonos / Slimserver may be implementations of UPnP protocols but then UPnP is not really a discrete "thing". I certainly agree that where UPnP is split into different servers and renderers/clients it all seems to go horribly
wonky - and I think Naim should perhaps be a little more circumspect in advertising the Uniti range on the strength of being able to use a wide range of computer based UPnP software. Not exactly Universal.

"Its a music server Jim but not as we know it"

Sonos / Slimserver are better than most examples of their kind.

I also agree that if using a computer as server - you are far more likely to get things working effectively if the machine is dedicated to serving music rather than anything else.

So far only Vortexbox has worked seamlessly for me and that is on a dedicated hardwired server.

It would have been simpler to just buy a UnitiServe but nowhere near as fun or entertaining. However, I may just do that, especially now that I know it is the only other way I will get things to work as they should - My dealer still describes the serve as an overgrown NAS.

Merry Christmas

Since when has Slimserver been UPnP? Surely it's a proprietary protocol. If it were UPnP you would be able to stream to any UPnP renderer - say a UnitiQute - from it, but you can't. And you would be able to play from any UPnP Server - say Twonky - to a Squeezebox, but you can't. Slimserver doesn't even show up as a UPnP Server on a network. Happy Xmas anyhow!

I suppose the universal part is not true of either so yes that's right but they are still just proprietary forms a hardly a good example of how to avoid Upnp. When Naim does proprietary they gets grief for it. Remember the open source threads? Happy Xmas to you too. No qualifications and thanks for the clarity.

and also a happy one for you Tog,
Naim would prefer you use one of their servers and make them for a reason. You can go another route effectively (reason for the earlier 'not for everyone' comment) as many have, (see "I have a UniQute and it works perfectly" ) but Naim have adressed both ends to effectively eliminate any 3rd party software or config issues for those that prefer that.
We're not in disagreement about Upnp as I also prefer the way an HDX accesses files but it's not Upnp in itsef that's the issue. It can and should work seemlessly when the 3rd party software is well written and the kit is up to snuff and works great when the server is known and dedicated.

Thinking about the original question surely we have to approach it by looking at the mechanics of getting the dormant file sat an our storage medium to our preamps, and do it in a manner that does not cause any fluctuation in the timing of the bits within this file.

Whereas there are many successful systems out there using streaming I for one cannot see how a streaming system over a network can totally avoid introducing some form of jitter into the playback as it is essentially an interrupt driven method of operating.

Streaming for me would seem to sit alongside multi-room systems as a convenience option. I don't mean this disparigingly but that it is inherently restricted albeit certain solutions available may at present be SOTA SQ wise

The issue for me then is can a dedicated playback system manage to transfer the bits at the correct times ie without having to resort or deal with IRQ's. Current SOTA and discussions on these boards suggests we are not there yet but without the burden of network software it should be an easier nut to crack.

Steaming far from just being convenient is starting to be taken seriously as the transport mechanism of choice.

No USB / Dig out worries - jitter is inherently lower and you don't have those ridiculous my cable is better than your cable arguments.

Linn jumped first - now view it as the way forward.

I just hate the man-cave "look at all my boxes approach"

Tog

Should we all only have surround receivers with ethernet inputs? Men comparing their boxes is not part of Naim's client profile. If they use more, it's only because they perceive a sonic benefit. Naim have introduced more multi function options then ever in the past but premium performance shouldn't be limited by ridiculous claims of box count being more important than reproduction. You can personallly disagree with the need but you don't get to assign false motive. What is that all about?

By the way, local source may still be best.

Agree totally with the comments about look at all my boxes!

Can't see that streaming would have inherently lower jitter issues as the network/ethernet software is in itself likely to introduce jitter because, as I understand it, it uses interrupts to communicate with the CPU. Unless the CPU can be dedicated to dealing only with the Audio stream and ignore all other inputs you will introduce jitter.

Hence my current belief that a stand alone source for playback, possibly from RAM, likely feeding a seperate DAC is the way to go. There will undoubtedly be lots of power supplies involved to get the box count up Even though this may not currently be yielding superior results to a networked/streaming system I think it is logically more likely to give the 'ultimate' performance.

If you already have a NDAC then this becomes the 'switch' for your digital sources, ie internet radio etc, a bit like a preamp for analogue. Again it does not follow for me that a multi-source box could sound better than a single source dedicated box all things being equal, so I am at the moment not overly interested in NDX/HDX and would rather wait for the picture to become clearer re digital playback

In the meantime I am happy to build my own music only PC and experiment with cheap componentry until Naim/Linn etc establish a clear improvement over this approach. By clear I mean one that almost all of us agree is superior. The fact there is a debate as to which is best to me says the differences are small.

Good luck with the ageement part. Small is relative to how good the file and post rendered system is. It's why all should take any post with a grain and make sure to have a compare for themselves.

Local is more flexible and sounds good to me - streamed via eyeconnect clumsy but reasonable, flac via vortexbox stream sounds even better.

Local control by apple remote 2 superb.

No insult intended about boxes but I think it is a reasonable comment on the motives of some - present company excepted.

Looking for simplicity as a route to quality.

Tog

Once the ratio of people backing one option over the other gets better than 60/40 split then that passes for agreement in the audiophile community IMHO. Then I figure something is worth listening to!

Re small being relative, I agree.

If you have the money then you will make the upgrade even if the difference is small.

I can not afford to dip my toe into the water too often for risk of being scalded. I want my new digital source to last 10 years plus and although it may be surpassed I don't want it to be made totally redundant, unusable or unsaleable.

At least in the meantime playing around with PC parts I can recycle bits into the kids PC's

and fun if you're so inclined.

quote:

Can't see that streaming would have inherently lower jitter issues as the network/ethernet software is in itself likely to introduce jitter because, as I understand it, it uses interrupts to communicate with the CPU. Unless the CPU can be dedicated to dealing only with the Audio stream and ignore all other inputs you will introduce jitter.

Understanding the differences between streaming types will help–largely, this has to do with where the file is being rendered to PCM.

In the case of an NDX pulling files to play from a UPnP server, the network is not part of the signal path–all sample clock timing occurs within the player itself, not over SPDIF. Signal paths are short and jitter / clock timing can be fully managed within the NDX, exactly like a CD player.

On the other hand–if you are using UPnP push streaming (say, from a PC application such as TVersity), it is fair to say that there may be some issues depending on network throughput (especially when re-streaming incoming audio streams from the PC to the UPnP player): there may be three different buffers at hand (in PC / out PC / in UPnP player).

This is dramatically oversimplified, but the proof is in the comparative demonstration–see your retailer!

David - Unitiserve to Uniti - push or pull?

Tog

Streaming has no inherent jitter; there is no clock signal embedded in the data, so no clock signal to recover, so no jitter. The DAC itself can (must) introduce some jitter of it's own, but how much or how little it does is entirely up to it.

quote:

Originally posted by David Dever:
Understanding the differences between streaming types will help–largely, this has to do with where the file is being rendered to PCM.

I did wonder whether the Uniti and Qute or any of the other Naim products buffer and re-clock S/PDIF inputs. If they do, this would help to reduce any difference between UPnP and S/PDIF inputs, but it does raise the question of what the happens if the souce clock is not running at the same speed as the clock in the Naim equipment

quote:

I did wonder whether the Uniti and Qute or any of the other Naim products buffer and re-clock S/PDIF inputs.

I'm pretty sure only nDAC is doing this.

quote:

Originally posted by AMA:

quote:

I did wonder whether the Uniti and Qute or any of the other Naim products buffer and re-clock S/PDIF inputs.

I'm pretty sure only nDAC is doing this.

...and NDX (according to the white paper).

Hook

quote:

Originally posted by Tog:
David - Unitiserve to Uniti - push or pull?

Tog

Single-client, single stream = "pull"
Single broadcast (proxied) stream = "push"

quote:

...and NDX (according to the white paper).

NDX does not exist at the moment

quote:

Originally posted by David Dever:

quote:

Originally posted by Tog:
David - Unitiserve to Uniti - push or pull?

Tog

Single-client, single stream = "pull"
Single broadcast (proxied) stream = "push"

Thanks David

Tog

quote:

Originally posted by AMA:

quote:

...and NDX (according to the white paper).

NDX does not exist at the moment

We'll be showing a production unit at CES!

quote:

Originally posted by likesmusic:
Streaming has no inherent jitter; there is no clock signal embedded in the data, so no clock signal to recover, so no jitter. The DAC itself can (must) introduce some jitter of it's own, but how much or how little it does is entirely up to it.

Sorry for the delay in posting - been on my hols.

I'm very interested in the first part of your post where you say streaming has no inherent jitter.

I can see that there is no clock signal embedded - that makes sense, but in my simple mind the cpu, whatever form it takes, is having to deal with a variety of inputs only one of which is the music data stream. If the cpu is being interrupted, in this case by the networking software saying 'I have a packet of data that needs to be passed on' but is also dealing with the mundane things like checking if the user has just pressed a button, it surely must introduce a disparity in the timing of the data packets arrival at the DAC. How does the DAC 'know' what the timing should be? This to my simple way of thinking is a source of jitter.

I don't know if this would make an audible difference, but I can't help but think it is not a 'good thing' to be happening. If you can make a system operate without this interference or to stream the music data stream without interruption (and probably with limited user control) then this would be inherently better. Whether it is audible or not is another question.

Until we know if this is audible then I don't think we can be sure which is the best way forward re streaming or direct dig out.

Keep it simple and avoid too much processing of the data stream. Much though I didn't expect it streaming to a good client to my ears sounds at least as good as if not better than digital out into a dac then into a preamp.

More cables/boxes/power supplies/clocks etcetera.

Keep it simple.

Tog

mike,

these interrupts would only compromise the sound with additional jitter if they are somehow related to the audio master clock. but normally you would only fill a buffer and have another clock which clocks out the audio data unrelated to the frequency at which the buffer is filled. With streaming you have the advantage that you have a flow control where the receiver (!) can tell the sender to send more or less data to control the buffer. so incoming rate does not matter at least if you always have a half full buffer.

but in general it is difficult to say which interface is better. and if you look at a dac design jitter is only one important thing but there are "hundreds" of other aspects to consider. so making a low jitter dac and failing with the other aspects does not make a good dac.