Mac Mini vs Naim ND5 XS

Frank Yang posted:

A DAC is a renderer, that is why a Naim DAC / NDS / NDX  sound different to a Chord DAC

I think I will put a stop here.

A DAC is a digital to analog converter. A renderer takes a music file and converts it into a digital music stream that the DAC converts.

DACs can and do sound different because of the way they reconstruct an analog signal.

Renderers can sound different if their conversion is not bit perfect, or if they create electrical noise such as RF that enters the DAC and in some way modifies the analog output.

Been reading this post with interest. I have gone the other way- ND5 to NDX and then to mac mini with the NDac Xps2 . Works great although both the ND5 and NDX are still great streamers. 

The cable between the man and the Dac made a fair bit of difference for me. The Vertere double DFi was the one i settled with. 

I would probably look to sell the V1 and get a decent SPdif  Converter with a used NDac. Power supply can be done later

The other thing I have found is Tidal Is worse v local files on Audirvana however the Tidal Masters ones sound even better

???? RICHARRD wrote,....The Vertere double DFi was the one I settled with. 

◾That is a good cable.!!

/Peder???? 

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

banzai posted:

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

Ieven if both rourptes are using the same DAC I can’t see how it can be other than so - of course whether and how different it may sound will depend on the renderer in the streamer, and on many other factors such as the RF isolation of the streamer to DAC compared to the RF isolation of MM output to DAC, any effect of the different cables, and any effect of other network components (e.g. switches) or setup.

And as already mentioned Toslink and USB are unlikely to sound the same, the effectiveness of RF isolation possibly being different (relevant if the DAC is susceptible), and in particular if by Toslink this means the MM’s inbuilt optical output as opposed to a USB to Toslink converter from a dedicated USB bus output the Toslink would be limited by the MM’s hardware and driver software.

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

Ieven if both rourptes are using the same DAC I can’t see how it can be other than so - of course whether and how different it may sound will depend on the renderer in the streamer, and on many other factors such as the RF isolation of the streamer to DAC compared to the RF isolation of MM output to DAC, any effect of the different cables, and any effect of other network components (e.g. switches) or setup.

And as already mentioned Toslink and USB are unlikely to sound the same, the effectiveness of RF isolation possibly being different (relevant if the DAC is susceptible), and in particular if by Toslink this means the MM’s inbuilt optical output as opposed to a USB to Toslink converter from a dedicated USB bus output the Toslink would be limited by the MM’s hardware and driver software.

Thanks IB.

I am not really concerned about how a DAC / Streamer deals with its input in this particular case, I just would like some clarifications about the Audirvana output, does it send the same digital data (musical info bit by bit) regardless whichever its output channel.

banzai posted:

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

Ieven if both rourptes are using the same DAC I can’t see how it can be other than so - of course whether and how different it may sound will depend on the renderer in the streamer, and on many other factors such as the RF isolation of the streamer to DAC compared to the RF isolation of MM output to DAC, any effect of the different cables, and any effect of other network components (e.g. switches) or setup.

And as already mentioned Toslink and USB are unlikely to sound the same, the effectiveness of RF isolation possibly being different (relevant if the DAC is susceptible), and in particular if by Toslink this means the MM’s inbuilt optical output as opposed to a USB to Toslink converter from a dedicated USB bus output the Toslink would be limited by the MM’s hardware and driver software.

Thanks IB.

I am not really concerned about how a DAC / Streamer deals with its input in this particular case, I just would like some clarifications about the Audirvana output, does it send the same digital data (musical info bit by bit) regardless whichever its output channel.

As far as I can assess the answer is no: leaving aside anything to do with RF, Toslink implementation, different DACs etc:

1) in its internal mode Audirvana renders the file into a digital music stream that goes direct to the DAC to be converted into an analog music stream.

2) in its UPnP mode Audirvana streams  the music file to a remote renderer, which renders it into a digital music stream that is fed into the attached DAC to convert into an analog music stream.

in respect of 2), if set up to so so, I understand that Audirvana may upconvert, or apply MQA first stage unfold, or  apply any chosen digital effects through Apple’s Aidio Units capability, then sending to the DAC a digital audio stream. I understand that when transmitting as in 1), the same digital effects can be applied, though here I am  hazy as to how any changes are made to the file before sending it to the remote renderer.

Thanks again IB.

The primary 

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

Ieven if both rourptes are using the same DAC I can’t see how it can be other than so - of course whether and how different it may sound will depend on the renderer in the streamer, and on many other factors such as the RF isolation of the streamer to DAC compared to the RF isolation of MM output to DAC, any effect of the different cables, and any effect of other network components (e.g. switches) or setup.

And as already mentioned Toslink and USB are unlikely to sound the same, the effectiveness of RF isolation possibly being different (relevant if the DAC is susceptible), and in particular if by Toslink this means the MM’s inbuilt optical output as opposed to a USB to Toslink converter from a dedicated USB bus output the Toslink would be limited by the MM’s hardware and driver software.

Thanks IB.

I am not really concerned about how a DAC / Streamer deals with its input in this particular case, I just would like some clarifications about the Audirvana output, does it send the same digital data (musical info bit by bit) regardless whichever its output channel.

As far as I can assess the answer is no: leaving aside anything to do with RF, Toslink implementation, different DACs etc:

1) in its internal mode Audirvana renders the file into a digital music stream that goes direct to the DAC to be converted into an analog music stream.

2) in its UPnP mode Audirvana streams  the music file to a remote renderer, which renders it into a digital music stream that is fed into the attached DAC to convert into an analog music stream.

in respect of 2), if set up to so so, I understand that Audirvana may upconvert, or apply MQA first stage unfold, or  apply any chosen digital effects through Apple’s Aidio Units capability, then sending to the DAC a digital audio stream. I understand that when transmitting as in 1), the same digital effects can be applied, though here I am  hazy as to how any changes are made to the file before sending it to the remote renderer.

Thanks again IB and apologies to the OP that I am diverting from his original message.

The primary reasons why I am interested in the streaming / UPnP are that:

• No funny effects from RF, jitters, cable limitations such as 24/92 
• Clean setup because of no USB isolator involved
• Ability to listen to Tidal Master, Qobuz because they are not supported by Naim
• No need to use Asset to stream music from a NAS because Audirvana provides a better solution, and hopefully a better sound. In fact, I think it does give a better sound

Innocent Bystander posted:

Renderers can sound different if their conversion is not bit perfect, or if they create electrical noise such as RF that enters the DAC and in some way modifies the analog output.

All possible.. however not being bit perfect is unlikely unless resampling or gain adjustment is used. Electrical noise is also possible but not that likely .. other than with ground plane isolation and modulation issues with cheaper equipment. The most likely cause of perceived sound differences from renderers is the system coupling with the DAC where the side effects of the intermodulation frequencies produces from a transport clock’s  stability. Any serialised data stream (USB, SPDIF, Ethernet etc) requires a transport data synchronisation clock.. and this clock itself can generate by products or artefacts which can couple via cross talk into other systems. And specifically analogue signal reconstruction circuitry.

Simon-in-Suffolk posted:

Innocent Bystander posted:

Renderers can sound different if their conversion is not bit perfect, or if they create electrical noise such as RF that enters the DAC and in some way modifies the analog output.

All possible.. however not being bit perfect is unlikely unless resampling or gain adjustment is used. Electrical noise is also possible but not that likely .. other than with ground plane isolation and modulation issues with cheaper equipment. The most likely cause of perceived sound differences from renderers is the system coupling with the DAC where the side effects of the intermodulation frequencies produces from a transport clock’s  stability. Any serialised data stream (USB, SPDIF, Ethernet etc) requires a transport data synchronisation clock.. and this clock itself can generate by products or artefacts which can couple via cross talk into other systems. And specifically analogue signal reconstruction circuitry.

I agree with your general remarks but, according to https://www.naimaudio.com/site...dac_august_2009.pdf, the Naim DAC overrides the implicit clocking of incoming S/PDIF streams with one of its internal clocks before the data enter the DAC stage. This suggests that, under normal operations (stable selection of the nDAC's internal clock), the amount of jitter associated with the data entering the DAC stage of the nDAC solely depends on the quality of the nDAC's internal clocks. In this case, the differences that we hear when we listen to different transports connected to the same nDAC (assuming that they all realize bit perfect streams) would in fact be due to electrical noise alone. Am I missing something here? Of course, other DACs might work very differently and be more sensitive to the clocking/jitter of the incoming streams.

banzai posted:

Thanks again IB.

The primary 

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

banzai posted:

Innocent Bystander posted:

A streamer is a renderer plus a DAC.

Hence you can have an Nd5XS or NDX etc acting as renderer feeding an external DAC. Or you can have a separate renderer like Audirvana, microRendu etc. Or one combined with a music store like in Melco, Innuos etc.

 

IB, are you saying (implying) that Audirvana streams different audio digital info to a streamer as opposed to a DAC via USB or toslink cables? Interesting!

Ieven if both rourptes are using the same DAC I can’t see how it can be other than so - of course whether and how different it may sound will depend on the renderer in the streamer, and on many other factors such as the RF isolation of the streamer to DAC compared to the RF isolation of MM output to DAC, any effect of the different cables, and any effect of other network components (e.g. switches) or setup.

And as already mentioned Toslink and USB are unlikely to sound the same, the effectiveness of RF isolation possibly being different (relevant if the DAC is susceptible), and in particular if by Toslink this means the MM’s inbuilt optical output as opposed to a USB to Toslink converter from a dedicated USB bus output the Toslink would be limited by the MM’s hardware and driver software.

Thanks IB.

I am not really concerned about how a DAC / Streamer deals with its input in this particular case, I just would like some clarifications about the Audirvana output, does it send the same digital data (musical info bit by bit) regardless whichever its output channel.

As far as I can assess the answer is no: leaving aside anything to do with RF, Toslink implementation, different DACs etc:

1) in its internal mode Audirvana renders the file into a digital music stream that goes direct to the DAC to be converted into an analog music stream.

2) in its UPnP mode Audirvana streams  the music file to a remote renderer, which renders it into a digital music stream that is fed into the attached DAC to convert into an analog music stream.

in respect of 2), if set up to so so, I understand that Audirvana may upconvert, or apply MQA first stage unfold, or  apply any chosen digital effects through Apple’s Aidio Units capability, then sending to the DAC a digital audio stream. I understand that when transmitting as in 1), the same digital effects can be applied, though here I am  hazy as to how any changes are made to the file before sending it to the remote renderer.

Thanks again IB and apologies to the OP that I am diverting from his original message.

The primary reasons why I am interested in the streaming / UPnP are that:

• No funny effects from RF, jitters, cable limitations such as 24/92 
• Clean setup because of no USB isolator involved
• Ability to listen to Tidal Master, Qobuz because they are not supported by Naim
• No need to use Asset to stream music from a NAS because Audirvana provides a better solution, and hopefully a better sound. In fact, I think it does give a better sound

I forgot to mention the most important reason /driver why I decided to use the Audirvana UPnP solution is that there is absolutely no "drop off", I think it is because we can afford to allocate a big inbound buffer on a Mac computer.

nbpf posted:

I agree with your general remarks but, according to https://www.naimaudio.com/site...dac_august_2009.pdf, the Naim DAC overrides the implicit clocking of incoming S/PDIF streams with one of its internal clocks before the data enter the DAC stage. This suggests that, under normal operations (stable selection of the nDAC's internal clock), the amount of jitter associated with the data&nbsp requires a transport data synchronisation clock.. and this clock itself can generate by products or artefacts which can couple via cross talk into other systems. And specifically analogue signal reconstruction circuitry.

Careful, you are mixing things up. Naim are talking about sample clock recovery from the transport stream. Sample clock recovery has not really been done this way since the early days of SPDIF , and so most devices these days work similar to the NDAC, and streamers and synchronise the serial stream to their own clocks thereby mitigating transport clock jitter directly from the sample clock.

i was referring to system cross talk. A serial stream clocked a clock that is modulated with noise will create frequency components related to the noise in connected systems through indirect and direct coupling. This is noise caused by crosstalk. This noise is added into the receiving system in various ways. 

It seems that many do confuse these two things. The former removes directly related transport clock jitter into the sample clock, but the latter introduces noise artefacts into connected systems independent in a way not directly related to the transport clock mapping to sample clock. That is why although a system can be said to reduce sample clock jitter, different transports of differeing clock stability can still sound different... what your hearing is system coupling and cross talk.

This is why in my opinion different Ethernet switches can sound different... it boils down to cross talk with connected devices from PHY layer synchronisation serial stream clock used on the Ethernet interfaces... and has little bearing on the data frame timing itself.

Simon-in-Suffolk posted:

nbpf posted:

I agree with your general remarks but, according to https://www.naimaudio.com/site...dac_august_2009.pdf, the Naim DAC overrides the implicit clocking of incoming S/PDIF streams with one of its internal clocks before the data enter the DAC stage. This suggests that, under normal operations (stable selection of the nDAC's internal clock), the amount of jitter associated with the data&nbsp requires a transport data synchronisation clock.. and this clock itself can generate by products or artefacts which can couple via cross talk into other systems. And specifically analogue signal reconstruction circuitry.

Careful, you are mixing things up. Naim are talking about sample clock recovery from the transport stream. Sample clock recovery has not really been done this way since the early days of SPDIF , and so most devices these days work similar to the NDAC, and streamers and synchronise the serial stream to their own clocks thereby mitigating transport clock jitter directly from the sample clock.

i was referring to system cross talk. A serial stream clocked a clock that is modulated with noise will create frequency components related to the noise in connected systems through indirect and direct coupling. This is noise caused by crosstalk. This noise is added into the receiving system in various ways. 

It seems that many do confuse these two things. The former removes directly related transport clock jitter into the sample clock, but the latter introduces noise artefacts into connected systems independent in a way not directly related to the transport clock mapping to sample clock. That is why although a system can be said to reduce sample clock jitter, different transports of differeing clock stability can still sound different... what your hearing is system coupling and cross talk.

This is why in my opinion different Ethernet switches can sound different... it boils down to cross talk with connected devices from PHY layer synchronisation serial stream clock used on the Ethernet interfaces... and has little bearing on the data frame timing itself.

Thanks for the clarification, I'll have to ckeck the notions of "cross talk" and "system coupling", I do not know what they mean precisely. But if the clocking artifacts of streams can have detrimental effects on sound quality in spite of being reclocked internally by the nDAC, then it is conceivable that streams generated by ultra accurate clocks could also have a negative effect on sound quality if their accuracy is not matched by the accuracy of the nDAC's internal clocks!