New NAS is Melco worth it?

Guys, when music is steamed, its not the file that is transferred. The file is broken down into separate components by the media server - so the media is handled separately from the attributes of the meta data for example and is transferred within different transfer type methods- the file's data structure when streamed looks quite different from the file itself. This is how UPnP DLNA works. Also whether the renderer pulls or has the media data pushed to it has no bearing on the 'clock'. This is purely HTTP terminology of pushing or fetching the data. Sample clocks etc are completely separate and totally unrelated to this data transfer process.

Simon

Returning to the OP's original question - is the Melco worth it?  If the component cost is the determining factor then the Melco N1A is priced at around  4x the cost of a NAS of similar technical capability which doesn't sound particularly good value, however, almost all reports suggest that the SQ when streaming from the Melco, at least via USB, is excellent and better than many well-respected steamers at twice the price. So it's really down to personal decision of whether it's worth paying a premium for the excellent  SQ.

yes I think if you have moved from say a Mac USB output to a Melco USB output - its going to be pretty impressive performance lift. My Macs are all fairly electrically noisy devices - the best behaved Apple device I have from a noise point of view has been an iPad Air!

S

Simon-in-Suffolk posted:

Guys, when music is steamed, its not the file that is transferred. The file is broken down into separate components by the media server - so the media is handled separately from the attributes of the meta data for example and is transferred within different transfer type methods- the file's data structure when streamed looks quite different from the file itself. This is how UPnP DLNA works. Also whether the renderer pulls or has the media data pushed to it has no bearing on the 'clock'. This is purely HTTP terminology of pushing or fetching the data. Sample clocks etc are completely separate and totally unrelated to this data transfer process.

Simon

I'm out of my depth here but and I don't want to link to another forum but if you google "RAAT and clock ownership" you will find an in depth explanation of what I'm trying to explain my limited knowledge of.

SJB

Roon looks fantastic. Your enthusiastic posts have piqued my interest in this SJB. Must drop Alan at Melco an email to see whether it is likely to make it onto the Melco. I think my (Hi-Fi) life would then be complete 

Sloop John B posted:

I'm out of my depth here but and I don't want to link to another forum but if you google "RAAT and clock ownership" you will find an in depth explanation of what I'm trying to explain my limited knowledge of.

SJB

Well I read the description by Brian Luczkiewicz and his method appears to describe optimising a TCP queue or window buffer - again nothing to do with sample clocks - certainly in quality renderers such as Naim. Further I am concerned that what he appears to define may interact possibly negatively with the specific  flow control mechanisms that Naim use in their TCP windowing mechanism..  but in any case has no bearing on sample clock..

In short with TCP data transfer I always ensure timing is decoupled from audio timing (in my professional world) that is you let the network transport define the timing and flow control not the application - if the audio is real time and uses UDP then it is quite different - and the timing of the data has a direct bearing on voice/audio quality. UPnP DLNA and Naim renderers use TCP

Simon

Simon-in-Suffolk posted:

Sloop John B posted:

I'm out of my depth here but and I don't want to link to another forum but if you google "RAAT and clock ownership" you will find an in depth explanation of what I'm trying to explain my limited knowledge of.

SJB

Well I read the description by Brian Luczkiewicz and his method appears to describe optimising a TCP queue or window buffer - again nothing to do with sample clocks - certainly in quality renderers such as Naim. Further I am concerned that what he appears to define may interact possibly negatively with the specific  flow control mechanisms that Naim use in their TCP windowing mechanism..  but in any case has no bearing on sample clock..

In short with TCP data transfer I always ensure timing is decoupled from audio timing (in my professional world) that is you let the network transport define the timing and flow control not the application - if the audio is real time and uses UDP then it is quite different - and the timing of the data has a direct bearing on voice/audio quality. UPnP DLNA and Naim renderers use TCP

Simon

I think RAAT does use UDP. 

Thanks for taking the time to read it, in reality it's all way above my head. 

SJB