High End NDAC on the radar?

quote:

Originally posted by Exiled Highlander:
If Naim had built just a streamer folks would have been asking for a standalone DAC.

Precisely the reason I have avoided the Linn line.

I'm not suggesting that the DAC be just a streamer, but that it should have an ethernet (and possibly wireless) input in addition to it's other inputs, so it could be streamed to. This is a major requirement of a whole class of potential users.

There is already a load of memory to support the ring buffer and the choose any-one-from-ten reclocking design. Why make a pc convert data into dodgy S/PDIF to load that buffer when the transfer could be done perfectly by ethernet? And without any need for 10 clocks - you could just use the right one.

NAIM are currently suggesting in the white paper that the DAC can be streamed to by using an apple Touch plugged into the USB socket running Plugplayer as a media renderer. Not exactly an elegant solution!

Likes,

If the DAC could stream, no doubt it would be over UPnP whcih I dislike more and more everyday.

patrick - upnp is the solution NAIM are suggesting at the moment, albeit mediated by the strange arrangement of a Touch running Plugplayer. I know on another thread it is being said that the uniti can't play back gaplessly, but I believe the Linn DS can manage to do so, so it can't be an inherent inadequacy of upnp. And if Linn can do it, surely the tea-boy at NAIM should be able to?

quote:

Originally posted by likesmusic:
I'm not suggesting that the DAC be just a streamer, but that it should have an ethernet (and possibly wireless) input in addition to it's other inputs, so it could be streamed to. This is a major requirement of a whole class of potential users.

There is already a load of memory to support the ring buffer and the choose any-one-from-ten reclocking design. Why make a pc convert data into dodgy S/PDIF to load that buffer when the transfer could be done perfectly by ethernet? And without any need for 10 clocks - you could just use the right one.

NAIM are currently suggesting in the white paper that the DAC can be streamed to by using an apple Touch plugged into the USB socket running Plugplayer as a media renderer. Not exactly an elegant solution!

There's so much wrong with that I have a hard time trying to figure out what you're asking. The number of clocks are there so you always have the right one. Regardless of where the music comes from, 44 and 96 will need different clocks unless you asymetrically upsample one or the other which means it can't be as accurate.

By definition, a unit that can play from an ethernet connection is a streamer and will need the protocols to change ethernet packets to a music stream. It's not like what comes off the wire (or wireless) can go right to the clock or DAC portion. After this is converted to a music stream, it would still go through the same buffer and oversampling to achieve the circuit's goal. The current high frequency clocks which have a great deal to do with the concept could not be the original reference and using a 44k clock and keeping it would get you back to the filter issues they have worked very hard to eliminate.

You have to rebuild the stream before you can sample it and allow the DAC to do it's thing.

js, just look at the block diagram on page 4 of the white paper. s/pdif comes in, goes through the SHARC DSP which unscrambles it into a RAM buffer, out of which it is clocked by the clock which best matches the average of the one in the input data. There is absolutely no reason why exactly the same data could not get into exactly the same buffer from an ethernet input, which would avoid all the uncertainty associated with s/pdif, in particular the uncertainty over the clock frequency inherent in it. The DAC would know which clock frequency to choose precisely, rather than having to select a (possibly changing) 'best match' to the incoming data rate. There are already different types of input; S/PDIF, USB/memory stick and USB/ipod. Why not add an ethernet input as well? No jitter, no uncertainty, just lovely packets of completely error free data.

quote:

Why not add an ethernet input as well?

No thanks - hopefully this will not happen - it means you'll need IP software (or equivalent) and you'll need to configure it and then you'll need a screen and then a keyboard and .... please no no no no no no .... just a DAC ... no networking required thank you.

I'd also like the remote to be optional as then I don't need to buy one.

@likemusic

I'm not sure that it is that simple, would that it were. The buffer in the NAIM DAC is, I believe, quite small and would probably need to be larger to manage the variances in delivery timing that would be inherent with ethernet (assuming a single clock controlling the bits from the buffer to the DAC gubbins). Additionally, the transport would likely be "pushing" the bitstream to the DAC - I say likely because I am not entirely sure, also necessitating a larger RAM buffer. The question then becomes how large does this buffer need to be - people who seem to know have told me that it would be large. Maybe this brings its own set of compromises - I have no idea - but I do know that engineering is largely a set of compromises. Everything is holistic - if that does not damn itself by being a tautology. For example, you increase the size of the RAM buffer and that - oh, I don't know - maybe increases the noise floor or something.

I remain convinced, though, that a connectivity solution that allows the DAC to "pull" the bits from the transport as and when needed would be (or is) the ideal solution. Simple buffering code would ensure the buffer is filled to optimal capacity by "pulling" more bits from the transport as required. But maybe this introduces a further set of compromises.

Anyway - I have had more than one large glass of red wine so this may have been complete nonsense.

To conclude - I remember reading a post that said the USB connection for iPod bypasses or does not use the rAM buffer. Can anyone confirm this? If so, it gives a very reasonable answer as to why the iPod sounds way worse than the CDX2 through the NAIM DAC.

Just wait, and when possible listen.

It will either be good enough to justfify the cost or not ...

Harry - an ethernet solution is a 'pull' solution. Any decent sized buffer (perhaps such as Linn use in their DS or Logitech in their Transporter) allows seconds for the DAC to ask for and then receive another packet of information across the network. No timing is involved. You say that a 'connectivity solution that .. allows the DAC to pull bits a an when needed is ideal'. Ethernet is exactly that, except that bits are pulled in packets. I am not talking about getting bits from a cd transport, which is a push situation where the DAC has to keep up, I am talking about getting (the same) bits from a computer. The ring-buffer is a good solution for a transport as it makes it, well, less 'pushy'. But if your data is on a computer in the first place, then ethernet is a great, utterly reliable way of shipping it about the place.

A DAC can't deal with packets nor does it ask for anything. An ethernet source needs to be rendered. It's not the right format until rendered and that's exactly what an Ipod via dig out does. It's the renderer that's required to output what the DAC can actually use. The DAC has a WAV player because almost nothing needs to be done to do so. That's a far cry from the case via ethernet.

Likes,

Just out of curiosity, why are you going on about this?

Is it simply because you want the Naim DAC to be a Streamer/DAC?

Its not. And it wont ever be.

It is getting rave reviews and exceeding expectations? What more do you want?

-patrick

magic

patrick, i would like an elegant way to connect it to a computer.

going from the usb port of a computer into an m-audio box of tricks into s/pdif and into the dac is not elegant. It is a kludge. Doing the same via an ipod touch and Plugplayer software is not elegant. It is a kludge. In particular, there is no guarantee and very little likelihood under such circumstances that the clock frequency selected by the DAC will stay the same for, say, the 40 minutes it takes to play a classical piecce of music. DACs and medie renderers, like the Transporter and Linn DS do, despite what js says, deal with packets of information delivered by ethernet. The packets of data can be the WAV data, or whatever else you want them to be.

Likes,

Despite all of my griping and strong feelings on particular matters, for some reason the method of connection isn't a concern of mine.

I would like a USB DAC (in theory), but trust Naim completely. If there are audible reasons to use a different route such as the "M-Audio transit method" or TC or HDX, over USB-direct, then I will change my mind about it.

I assume the same goes for ethernet. Can you comment on how the Linn, SB compare in SQ to the Naim DAC? Maybe it is a sum of the parts kind of deal. If you maximize the performance of many small details, that individually are not perceivable, you can increase overall quality. Or possibly impart a different flavor to it.

Maybe your ethernet solution is best kept in another box not unlike the power supplies for pre amps and CDPs.

-patrick


I am using the transit currently and it seems to work wonderfully.

quote:

Originally posted by likesmusic:
patrick, i would like an elegant way to connect it to a computer.

6" USB cable to
M-Audio Transit to
toslink cable

Is it really that bad?

quote:

Originally posted by pcstockton:

quote:

Originally posted by likesmusic:
patrick, i would like an elegant way to connect it to a computer.

6" USB cable to
M-Audio Transit to
toslink cable

Is it really that bad?

Or, if you have Mac (or onboard card with an optical SPDIF out), the connection is just a Toslink cable. Fairly elegant IMO.

[QUOTE]Originally posted by likesmusic:
Harry - an ethernet solution is a 'pull' solution.

Maybe on some other planet but not on this one

[QUOTE]Originally posted by pcstockton:
Likes,


If there are audible reasons to use a different route such as the "M-Audio transit method" or TC or HDX, over USB-direct, then I will change my mind about it.

-patrick


/QUOTE]

More than audible reasons I think Naim just hasn't focused on how to stream properly from a computer. They trust in spdif but they don't offer "yet" an optimum link. I hope one day they will offer some alternative to the "M-audio transit method". I also think this is no elegant at all.

quote:

Originally posted by BobF:
[QUOTE]Originally posted by likesmusic:
Harry - an ethernet solution is a 'pull' solution.

Maybe on some other planet but not on this one

How do ethernet printers work on your planet then?

quote:

Originally posted by likesmusic:
patrick, i would like an elegant way to connect it to a computer.

going from the usb port of a computer into an m-audio box of tricks into s/pdif and into the dac is not elegant. It is a kludge. Doing the same via an ipod touch and Plugplayer software is not elegant. It is a kludge. In particular, there is no guarantee and very little likelihood under such circumstances that the clock frequency selected by the DAC will stay the same for, say, the 40 minutes it takes to play a classical piecce of music. DACs and medie renderers, like the Transporter and Linn DS do, despite what js says, deal with packets of information delivered by ethernet. The packets of data can be the WAV data, or whatever else you want them to be.

DAC and media renderer are 2 different things. You want an all in one that has an interface etc, not a DAC. That's fine but not when evaluating a DAC. It's a DAC. You want more. Put the more in front of it or just look elsewhere. Your beating a dead horse. Why constantly berate it for not being something it isn't. My Ferrari can haul manure so it's shite. Other vehicles do it.

Lot's of people store music files in formats other than wav. It would be even sillier to put ethernet rendering in a DAC without facilities for these besides. It's an all or nothing proposition. What comes down an ethernet connection is not in music stream format and must be rendered to that before any DAC can deal with it. The Naim DAC can play wav packets directly because they built in a wav renderer but would not be able to do direct playback of ethernet packets without additional rendering even if it could accept them. Big difference in accepting and rendering the 2 formats. Besides the reciever and protocols, you need a controller, multi format renderer and access to it via a display somewhere.

As Naim claims that S/Pdif is not an issue with this DAC, direct ethernet is not an advantage other than conveience and I would suspect that at some point in time there will be more Naim player options on this front but that's just an educated guess. Perhaps they prefer to keep that circuitry separate for electrical and noise isolation. You also didn't address the clocking scenario of how the incoming stream clock can't be the same as that used in decoding for their topology and clock drift just doesn't happen unless you lose the source clock info entirely. I have used lots of DACs for lots of years and none of them lose lock unless the DATA is corrupt. At that point any system goes to shite. The info is there or not. You have an unusual conceptual models of what's happening here.

This sure doesn't look like a something a DAC should see. You may claim the DATA is all there in the DATA field but with out checks and then being rendered to a non packeted stream it is a foreign language to a DAC.
Starting Delimiter (1 byte) Destination Address (6 bytes) Source Address (6 bytes) Length (2 bytes) LLC header and Information field (46 - 1500 bytes) Frame Check Sequence (4 bytes)

I forgot to mention that the DS you're comparing to aren't DACs anymore than a CD player is a DAC. No dig in. That's a very important difference to me but inconsequencial for others yet I don't consider it a flaw. Evaluate things for what they are and how well they do their jobs and leave it at that. Whether or not it meets your particular needs is entirely personal and for you to decide but your personal desires have nothing to do with it's competence.

js, do you connect your printer to your pc via s/pdif?

And the answer is 42.

quote:

Originally posted by likesmusic:
js, do you connect your printer to your pc via s/pdif?

No, but neither do you send directly the rendered information to a printer via ethernet. You use a special language (PCL or Postscript) which describes the contents of the page the printer then renders this into individual dots on the page. In a similar way a UPnP streamer renders the WAV files into digital "dots" which are sent to the DAC via SPDIF.

Maybe the analogy isn't 100% exact but hope it shows the difference. The WAV files sent to the UPnP renderer is the equivalent of the postcript information sent to the printer.

Eloise