DAC-free streamer; modular approach

The MAC was just an example.

I'm using a Zotac ID01, Wind 8 and JRIVER.

Interesting info re he purpose of galvanic isolation.

So, in your view, what is it about Naim streamers and Naim servers that is not present/present in a computer that causes high frequency noise ?

Jude 

I believe its the regulated power supplies, careful design of the digital path, careful cross talk decoupling  and well designed board layout  with the careful use of precision clocks and well designed digital driver/ buffer electronics producing minimum rising edge distortion. 

No that would be comparing quite separate and unconnected things.

USB and SPDIF are transport methods for timed sample data - where the value in time is determined by the point in time.

Ethernet using TCP (as we do for UPnP media transfer) has no concept of this.. the data is packaged up with only relative implied timing. Therefore it  has to be re assembled and  rebuilt by the receiver and the absolute timing re-injected into the data so it once again can become a stream of samples - so it can then be sent via  asynchronous/ synchronous USB, SPDIF or I2S. 

If the sample data has been decoupled from time - such that is the case when sent via TCP over the Ethernet - it can't introduce any timing jitter into the data stream - as there is no timing to cause jitter with. Once you reintroduce absolute timing then jitter becomes something you need to manage.

+1 for a dac-free streamer. 

For me the ideal would be a Naim version of the Sonos Connect - all the ease-of-use and versatility of Sonos (including easy access to Qobuz and the like) but with Naim hi-fi quality and 24/192 capability.

The other thing that's important for me is lossless multi-room, albeit the system would have to be wired rather than wireless for anything above CD quality.  I'm not aware that any hi-fi quality streamer will do lossless multi-room - the current Naim ones all reduce to 320kBs.

Claus

thx

have to think about it.

especially in case that the DAC v1 Runs in bit perfekt

I can definitely say the USB to SPDIF converter between my Fit-PC3 and my nDAC has an impact on sound quality.

The M2Tech hiFace Evo sounded slightly better than the cheaper hiFace Two. Whether this is related to galvanic isolation (apparently implemented on the Evo but not on the Two) or to other technical aspects, I do not know. I have not tested other converters beside these two but a quite comprehensive comparison of different USB to SPDIF devices can be found here. I have to admit that I found this result a bit disappointing: I would have expected the nDAC to be more source agnostic.

That said, I have to admit that what I consider to be lacking in virtually all solutions I have seen so far is not sound quality but software quality. This holds both for open source and for proprietary software. I am of course interested in getting the best possible sound quality from my components but, at this level, I consider software to be the major limitation in the experience of music replay.

MPD, for instance, supports searching and browsing your music collections by "genre", "year", "performer", "composer", "filename", "album", "artist" and "title". I understand this is not worse (and, possibly, even better) than what most UPnP servers and Naim solutions currently support but it is still less than acceptable.

I would expect any decent music player or server application to support customizable tags. I have classified my music collection according to a number of criteria, among others period (medieval, renaissance, baroque, classical, romantic, modern, etc.), instrumentation (orchestra, chamber, violin, piano, etc.), composition (serenade, symphony, etude, partita, etc.) and a few more. Why should I not be able to search my collection according to my own criteria?

With a few exceptions, all solutions I have seen so far force one to introduce user-specific searching criteria as values of one of the three or four standard tags (genre, artist, album, composer, ...) Apple has decided are good enough to classify the whole world of music (in this sense I very much sympathise with Underhill's sentiment towards Apple products although my personal view is that the evil is very much concentrated in Apple's most recent range of products: iOS, iTunes and iDevices.)

I tend to perceive the lack of customizable software solutions as an insult to the user and I expect companies that have the ambition (or raise the claim) of delivering solutions for music enthusiasts to do better in this respect. In fact, the lack of decent software solutions is the major reason why I am not considering investing in new hardware at the moment, no matter whether this comes from Naim or from other manufacturers.

A single NAS can serve multiple streamers throughout the house via UPnP/DLNA, but just one, nearby, via USB. I just got a SOtM sMS-100 streamer (runs Sonic Orbiter software) to power a DAC+headphone amp, first impressions are good but I need to complete my home wiring as there is too much radio interference here to rely on WiFi for streaming. 

+1 Simon, thanks for the very clear explanation/reminder! Is there any specific reason why data sent/received over SPDIF are not treated exactly as data sent/received over TCP/IP? In principle it should be possible for a dac to neglect any time correlation in SPDIF data, I would expect. Is there any reson why the data cannot be fully buffered and reclocked? Thanks, nbpf

Try JRiver - it does pretty much everything you're asking - certainly the custom tagging, and "smart" playlists based on tags. Also great search & editing of all metadata (composer, orchestra, and even custom fields you want to add.)

The real limitation is the quality of the metadata - for your custom genres you'll need to enter in all that data yourself.   I use a combination of dbPowerAmp for ripping (and customizing metadata when I rip) + Bliss for ensuring library stays organized running on my VortexBox (essentially a UPNP server / hard drive) + JRiver and JRiver remote as control software.

iTunes isn't designed as an audiophile (or classical music) solution and you can't edit the data.

However, since I got Tidal I've hardly bought or ripped a CD.  I've been buying LPs and Hi Res downloads.

Ragman,

Ok try this...

A packaged set of 1 bit samples reads

10010010010110

As such that can be stored in a file or sent via TCP over the ethernet

Lets say the actual samples were originally recorded at  7 samples per second.

Therefore if I reintroduce absolute timing - and play 7 samples every second, at one second my sample value would be '1' and at two seconds by sample value would be '0'

Now if i instead introduced an absolute playback clock of 6 samples every second, at one second my sample value is '0' and two seconds my sample value would be '1'

Nothing has changed in my relative sample data - it is still 'bit perfect' its just my absolute clock has changed.

So if my absolute clock is changing through jitter - and so say is  nominally  7 samples a second, but as an extreme example if after one second it only streams 6 samples and then then at two seconds streams 8 samples, my value at one second would '0' and at two seconds the value would be '0'.

Everything is still bit perfect, but we can see how the master timing when reintroduced actually changes the sample value at a point in time.

I know it is a little simplistic but hope it makes some sense for you.

Thanks for the feedback mutterback! Jriver and Quodlibet are in fact the only two players/servers I have heard about that support customizable tags.

I have not tried Jriver already because I do not really want to run a full Windows system (with window manager, application software, etc.) as a music server. I am not very comfortable with Windows systems in general but I have one running on my laptop in a virtual machine and I will try Jriver on it. I do not like heavyweight solutions, however and I had the impression Jriver was one such tools. I am probably mistaken.

I would have tried Quodlibet if it was a client-server solution like MPD. But as I understand, Quodlibet is just a player, not a server that can be controlled by client applications. I am looking for a solution that I can control via clients from laptops, iPads and the likes.

No - there isn't - its just at some point the sample data has to to be timed - a DAC could, and clearly some do, have an ethernet interface and then use internal interfacing to clock the data to the DAC.

A common internal interface standard is I2S which is a separately clocked interface that is very effective over very short distances.

Of course data can be rebuffered and rechecked - in the limit a filling buffer has the same issues of a receiving DAC. However in practice where the clock jitter is very fine - which most are - then jitter can be effectively removed - but it would appear cross talk from the de jitter circuity unifying the timing can introduce other artefacts possibly seen as new jitter into the reconstructed streamed signal. We are talking minute variations here - but our auditory system appears very sensitive to very slight changes in the make up of the reconstructed audio.

However as I remember from my system theory lectures all those years ago at university - when work is expended in achieving an outcome through a function in a closed system there is in practice a by-product or error produced as part of the function output.. and this is essentially I believe what is happening here

Simon

The S/PDIF Wikipedia page (http://en.wikipedia.org/?title=S/PDIF) has a pretty good discussion. S/PDIF was designed as a synchronous, unidirectional digital audio protocol. Someone I guess could interpose a buffering and reclocking unit between a S/PDIF receiver and downstream processing (although I don't know if that would be allowed in jurisdictions that block copy protection circumvention, given that S/PDIF's design includes copy protection). In contrast, UPnP is built on top of Internet protocols that provide directly in the protocol (TCP) or through application code (UDP) bidirectional flow control, data loss and corruption recovery, and buffering. Thus, UPnP streams are inherently asynchronous and real time for D to A has to be reintroduced by clocks downstream of the receive buffer.

Fernando, the copy protection bit in the consumer SPDIF header is probably largely ignored these days  as with DACs its mostly meaningless  - and  most copying is performed using non timed data - i.e. flat files of sample data or lossy sample data - rather than copying streamed digital audio via coax - as was common in the 90s.

TCP is a reliable transport for transporting blocks of data, like chunks of a flat file - there are no absolute timings. TCP uses a windowing, resend and flushing mechanisms to reliably reconstruct the payload and pass the file up to the application. It is ideal where latency is not important.

UDP is a datagram protocol - its fire and forget - and all recovery has to be done by the application. It is not used by UPnP for media transfer - but it is used for multicast discovery and management functions as it is quick - and can split one to many.

In commercial setups using VoIP then UDP is used for carrying voice - but careful consideration of network quality of service is required - as there is no recovery and the timing is essential. UDP is used in this context as it is low latency - such as required for commercial voice applications.

@nick - remember, the only two things you need to worry about in digital audio are data and timing.  Getting the right data is trivial and the DAC takes care of the timing, so in reality there is nothing to worry about.

Simon, I am probably missing something very obvious but I would expect data which have been received by a dac and buffered to be processed in exactly the same way as locally stored data. For instance, as data stored on a USB stick or SD card mounted on the dac. I can very well imagine TCP and SPDIF to have very different data transfer costs and quality and therefore yield different buffer values for the same source data. But I would expect what happens down the replay chain to be the same in both cases. I understand this is probably not what happens in the current practice. But the question is whether there are any fundamental reasons why it could not happen this way. Best, nbpf

The Moon Mind 180 Music (DAC-less) Streamer is garnering quite positive reviews (US$ 1300). Search 'Sound Stage Moon Mind'. The reviewer found the streamer to be virtually indistinguishable in sound from the streaming section of a Linn Akurate DS.

The Devialet chat forum has some interesting comparisons of a few DAC-less streamers.

J-E

Unless there are bugs on the network stacks of the sender or receiver, bits sent via TCP are faithful. USB should behave similarly, at least in asynchronous mode with enough buffering. I don't know enough about S/PDIF to know if timing or other issues might corrupt the bit stream. Given a good buffer of bits, a DAC should do an identical job independently of the source. However, both hardware and software could conspire to cause differences. On the hardware side, different sources have different electrical characteristics that propagate electromagnetic noise through the DAC's power and analog circuitry in different ways. On the software side, bugs are not unheard of.  Recently I tested a streamer+DAC (brand left out to protect the guilty) that showed terrible analog behavior because of bugs in their implementations of standard UPnP and AirPlay features. Naim's UnitiQute with the latest firmware works well with the latest Synology NAS Media Server and Naim's Android app, but I've had a variety of problems, some affecting sound, with earlier Android apps and Naim firmware versions. The complexity of UPnP protocol stacks, the underlying Internet protocol stacks, and the operating systems that support them should not be underestimated. Any software system that complex has many bugs, and the small size of the UPnP renderer and high-quality DAC markets means that the resources available for hiring the best developers, testing, and bug tracking are rather constrained. Asynchronous USB directly from the source reduces this complexity a lot, not the least because the market for USB chips is huge and high-res audio can benefit from the very low marginal cost of those parts. I was recently doing research on this, and I was struck by the contrast between the variety of well-reviewed asynchronous USB DAC+headphone amp at all price points from a few $100, with a sweet spot between $500 and $1500, and the rarity of comparable devices with UPnP input, with the only real options being either carefully selected separates costing together well over $1000, or integrated units costing $6000 or more.

Nbpf, you are right the processing is the same. The key thing as I tried to explain, sample data in a file,or transferred via ethernet is inert.. It's simply a sequential block of samples with implied timing. A sample stream from a USB stream, SPDIF or I2S for example is stream of timed samples. That is there is no block of samples, just a value at a specific point in time governed by the sample transport clock. Therefore this clock becomes as important as the sample values themselves in reconstructing the audio.

Another way of looking it is that a flat file or ethernet payload is like a buffer or a sequential series of buffers  full of sample data. A clock is needed to spool the data from the buffers off into a stream ... This then is processed in the same way as the sample stream above.

Its  only the sample stream (with the absolute timing) that has concept of jitter.

Simon

Simon, I understand the difference but I was wandering whether, in a fully buffered context, the time information implicit in a USB, SPDIF or I2S stream could not simply be discharged. Only the order in which data are received would matter an timing could be reintroduced later as for data received via TCP.

I understand that this is not what happens in most dacs, but I do not see any fundamental reason why it could not happen. USB is routinely used to transfer data to all sort of storage devices, including the drives we use to store our music files. A dac could store incoming USB data in a local memory and only start replay after the data transfer has been succesfully completed, I reckon.