Melco Audiophile NAS

[simoncn]

(08-01-2015 12:04)best Wrote:  Giso lan isolator from acousence. Also tried the lan isolator from acoustic revive, but preferred this one. It is connected between pc and router. Linear power supply from teradak.

Thanks!

Quote:Will you get a chance to compare the two models? Main difference seems to be in the separate power supply and the drives?

I don't think it will be possible for me to do this comparison.

[best]

(08-01-2015 12:51)simoncn Wrote:  

(08-01-2015 12:04)best Wrote:  Giso lan isolator from acousence. Also tried the lan isolator from acoustic revive, but preferred this one. It is connected between pc and router. Linear power supply from teradak.

Thanks!

Quote:Will you get a chance to compare the two models? Main difference seems to be in the separate power supply and the drives?

I don't think it will be possible for me to do this comparison.

One last question: When you import your files from your existing collection to the melco, does it retain the same directory structure? As in if your library is viewed in 'folder view' do you see separate folders?

Thanks

[simoncn]

(08-01-2015 18:49)best Wrote:  One last question: When you import your files from your existing collection to the melco, does it retain the same directory structure? As in if your library is viewed in 'folder view' do you see separate folders?

Thanks

I am copying the files using Linux commands, which ensures my preferred directory structure is preserved. I haven't yet tried using the Import facility described in the User Manual. I will try using Import and report back.

[Fritz]

(13-12-2014 21:48)DavidHB Wrote:  

(13-12-2014 20:03)beckphotonik Wrote:  I was considering an SSD loaded Qnap that would have set me back £1100!

... and the Melco SSD device costs £6,200. You can buy a lot of hi-fi for the difference, so the Melco has to be special to stand out to that extent in the market place. Simon is making the point that it is a bit special. I'll go along with that assurance, as we all have reasons to trust Simon's judgement on these issues, but I'd want to understand a bit better what is going on before contemplating a purchase of that kind.

(13-12-2014 20:03)beckphotonik Wrote:  Even so it would not be as elegant as the Melco solution.

I think the point about the Melco solution is not so much that it is elegant (though it is), but that it is different from what has gone before. We have seen a variety of attempts to improve performance by creating a dedicated or isolated network, and by putting the music system on a different subnet. What seems to be happening with the Melco approach is that the NAS (or rather its networking component) is not isolated in that way, but 'cleans up' the part of the network that connects to the player.

Simon's experiments suggest that it doesn't matter so much where the stream originates (which is good news in regard to sources such as internet radio); what matters is that the player is connected to the specially configured and powered network port on the NAS. I cannot think of any other device that takes this approach (though would be glad to be corrected if there is one), and it does seem from the product description and specifications of the Melco that the audio-oriented work on the networking components has been rather thorough. This is what one would expect from a company which (Simon told us) has a respectable history in both audio and networking - a somewhat unusual pedigree, I think.

Be all that as it may, enjoy the QNAP ...

David

I agree with Simon that the Ethernet is "bit-perfect". If not I stop Internet banking immediately ... :-) .

So I understand that the underlying copper technology could have an impact on the sound through the streamer's Ethernet circuitry. Question: To test this shouldn't a piece of optical fiber and pair of media converters be enough? Checking at amazon that would be somewhere in the 50€ range. Interesting discussion and I am tempted to test ...

[beckphotonik]

(10-01-2015 18:48)Fritz Wrote:  

(13-12-2014 21:48)DavidHB Wrote:  

(13-12-2014 20:03)beckphotonik Wrote:  I was considering an SSD loaded Qnap that would have set me back £1100!

... and the Melco SSD device costs £6,200. You can buy a lot of hi-fi for the difference, so the Melco has to be special to stand out to that extent in the market place. Simon is making the point that it is a bit special. I'll go along with that assurance, as we all have reasons to trust Simon's judgement on these issues, but I'd want to understand a bit better what is going on before contemplating a purchase of that kind.

(13-12-2014 20:03)beckphotonik Wrote:  Even so it would not be as elegant as the Melco solution.

I think the point about the Melco solution is not so much that it is elegant (though it is), but that it is different from what has gone before. We have seen a variety of attempts to improve performance by creating a dedicated or isolated network, and by putting the music system on a different subnet. What seems to be happening with the Melco approach is that the NAS (or rather its networking component) is not isolated in that way, but 'cleans up' the part of the network that connects to the player.

Simon's experiments suggest that it doesn't matter so much where the stream originates (which is good news in regard to sources such as internet radio); what matters is that the player is connected to the specially configured and powered network port on the NAS. I cannot think of any other device that takes this approach (though would be glad to be corrected if there is one), and it does seem from the product description and specifications of the Melco that the audio-oriented work on the networking components has been rather thorough. This is what one would expect from a company which (Simon told us) has a respectable history in both audio and networking - a somewhat unusual pedigree, I think.

Be all that as it may, enjoy the QNAP ...

David

I agree with Simon that the Ethernet is "bit-perfect". If not I stop Internet banking immediately ... :-) .

So I understand that the underlying copper technology could have an impact on the sound through the streamer's Ethernet circuitry. Question: To test this shouldn't a piece of optical fiber and pair of media converters be enough? Checking at amazon that would be somewhere in the 50€ range. Interesting discussion and I am tempted to test ...

If you do, please let us know how you get on. I suspect it is more than just electrical isolation. My guess, and it is a guess, that the Melco does some form of IP filtering too so the streamer gets only the audio and control packets it needs and nothing else. How and why that should make a difference I don't know but from what Simon has reported, something interesting is definitely going on.

[DavidHB]

(10-01-2015 18:57)beckphotonik Wrote:  I suspect it is more than just electrical isolation. My guess, and it is a guess, that the Melco does some form of IP filtering too so the streamer gets only the audio and control packets it needs and nothing else. How and why that should make a difference I don't know but from what Simon has reported, something interesting is definitely going on.

My guess - again no more than a guess - is somewhat different.

It's (relatively) easy to verify that the data which is arriving at the player is bit perfect. What is harder to verify is that it is arriving at the DAC at a time when the player's timing controller can actually ensure it is decoded at exactly the right instant. We know that caching is supposed to take care of timing differences, and does so, at the gross level where the player would otherwise be waiting for data. What we don't know is whether there are other timing issues (jitter) that caching cannot handle completely. Melco are claiming reductions in jitter.

The published data suggests that what is different about the Melco port is that it incorporates an opto-isolator. This, presumably, filters out electrical noise and so 'cleans' the data stream reaching the player. If the combination of Ethernet port, timing controller and DAC in the player can handle this cleaner signal more accurately (that is with less jitter), there could be sonic benefits.

My understanding of RTP (the network protocol used for media streaming) is that packet filtering would only prevent packets being sent to the player which its network controller would not accept in any case. I can't really see how that would affect sound quality, or indeed how it could explain the change that Simon noticed when he used the Melco cable. So my guess, as it was at the top of this thread, is that whatever is going on relates to electrical noise/signal quality/timing/jitter. But, although it is consistent with what Melco say about their product, it's still pure speculation.

On a quite separate point, it has occurred to me that the Melco architecture does have one potentially serious limitation. That is, with only one port to serve a single player, the NAS can only provide its particular benefits to one room in a multi-room system. So, if Simon's preliminary findings are correct, what we actually need is not so much an audiophile NAS, but audiophile switches at every node to which a player is connected. Or maybe the LAN isolators mentioned by best - a snip at $464 each, if I understand the pricing correctly. That's still a fair bit cheaper than a £6,200 NAS, however.

David

[simoncn]

(10-01-2015 20:39)DavidHB Wrote:  My understanding of RTP (the network protocol used for media streaming) is that packet filtering would only prevent packets being sent to the player which its network controller would not accept in any case.

UPnP audio streamng uses HTTP, not RTMP (as I presume you meant to say). Packet filtering (if this is happening) might be removing some extraneous packets, but I doubt that this is the reason for the sonic difference. I think it is more likely to be related to the electrical signals that are used in packet transmission.

[DavidHB]

(10-01-2015 21:03)simoncn Wrote:  UPnP audio streaming uses HTTP, not RTMP (as I presume you meant to say).

Actually, I did mean RTP (aka RTTP) rather than RTMP. But as I was wrong in either event, that hardly matters. It's interesting that the originators of UPnP chose to use HTTP, as the references I looked up indicated that HTTP is not designed for real time communications, and identified RTP as the protocol for streaming. If I'd started at the right end, and refreshed my memory on UPnP, I wouldn't have been caught out ...

(10-01-2015 21:03)simoncn Wrote:  Packet filtering (if this is happening) might be removing some extraneous packets, but I doubt that this is the reason for the sonic difference. I think it is more likely to be related to the electrical signals that are used in packet transmission.

I agree.

David

[simoncn]

(11-01-2015 01:00)DavidHB Wrote:  Actually, I did mean RTP (aka RTTP) rather than RTMP. But as I was wrong in either event, that hardly matters. It's interesting that the originators of UPnP chose to use HTTP, as the references I looked up indicated that HTTP is not designed for real time communications, and identified RTP as the protocol for streaming. If I'd started at the right end, and refreshed my memory on UPnP, I wouldn't have been caught out ...

Thanks for this pointer. It seems that RTP plays a similar role to Linn Songcast with support for multicasting and real-time delivery of audio packets. In contrast, UPnP streaming normally uses buffering in the renderer, which would make the real-time capabilities of RTP redundant for this usage.

[DavidHB]

(11-01-2015 10:09)simoncn Wrote:  Thanks for this pointer. It seems that RTP plays a similar role to Linn Songcast with support for multicasting and real-time delivery of audio packets. In contrast, UPnP streaming normally uses buffering in the renderer, which would make the real-time capabilities of RTP redundant for this usage.

We may both be getting muddled (my fault, I fear). My understanding now is that RTP/RTTP is a transport layer protocol, and so is a counterpart to TCP/IP rather than HTTP. TCP/IP is documented as being unsuitable for real-time use (as it favours reliability over timeliness), so, if UPnP actually runs in HTTP on TCP/IP (I haven't managed to check that point), you can see the need for buffering. I think I'm in danger of going off topic, so I'll leave it there.

David