Ethernet vs. local USB interface

[blanc]

Hi,

Does it make any difference on sound quality if the data is received by a streamer over Ethernet or local USB interface?

 

[staticV3]

If both setups are working properly, then there will not be a difference in sound quality.

 

[Vincent Kars]

Assuming the local USB is a USB memory device, either your streamer plays its content or not. If a codec like APE or TAK is not supported, it won't play.

Streaming is far more complex. UPnP is a pun on USB's Plug and Play. Indeed server and renderer exchange their capabilities. If the renderer don't support APE, the server wil transcode it to a supported format e.g. linear PCM. If you use Airplay2, it is gapped at 24/48 so no high res without down sampling. Likewise Apple Music is said to convert to AAC (lossy) when streamed of=ver a network.

I won't say all of this is audible but for sure streaming over a network is far more complex and under the hood all kind of conversions might take place.

 

[MaxwellsEq]

My FLAC files are stored on a NAS. My "streamer" mounts the filesystem using CIFS/SMB protocol over IP. It reads blocks off the NAS and converts them to PCM via S/PDIF into the DAC. There's no audible difference between this approach and plugging a USB filesystem into the DAC's USB port.

 

[blanc]

I suspect in most cases Ethernet is as good as USB but what happens if a movie is transferred at the same time? Does the streamer have a buffer for Ethernet data?

 

[Vincent Kars]

Does the streamer have a buffer for Ethernet data?

By design.
Ethernet is packaged based. There is no guaranteed delivery time and no fixed route. The answer: a big buffer.

 

[MaxwellsEq]

I suspect in most cases Ethernet is as good as USB

If configured correctly USB and Ethernet are the same in terms of performance. Always.

what happens if a movie is transferred at the same time?

It just works. I can have several movies and multiple audio streams running over the LAN without any issues.

 

[audio_tony]

I won't say all of this is audible but for sure streaming over a network is far more complex and under the hood all kind of conversions might take place.

The storage device (server or nas) will transmit the packet over TCP/IP which is an extremely robust protocol.

Additionally, networks have abundant capacity to transmit audio, and if a packet is dropped, it will be retransmitted before the player software even knows it's been lost (the network stack on the client handles all the network I/O - the player simply receives the data from the network stack).

I suppose it could be argued that conversions could take place in the OSI layer - however, it's all just data.

Therefore whilst streaming appears far more complex, realistically all need to be concerned about is having a reliable network connection.

It might be worth reading Archimago's intercontinental streaming test.

Conclusion?

there is no evidence that locating the server >7000 km away did anything to the output quality of the Transporter. Neither the RightMark results nor the Dunn J-Test suggests any change beyond what I normally expect from inter-test variation.

And this test was conducted back in 2015 - 8 years ago....

MEASUREMENTS: The Intercontinental Internet Audio Streaming Test...

A blog for audiophiles about more objective topics. Measurements of audio gear. Reasonable, realistic, no snakeoil assessment of sound, and equipment.

archimago.blogspot.com

On a local network, you have absolutely nothing to worry about. Data transmission will be bit perfect.

In my own local testing, I have streamed flac files and maxxed out my network connection with test software simultaneously.

Did the music stutter? No it didn't.

Think about this; it's possible to stream HD video content across the internet on a relatively basic internet connection without any stuttering or picture break up.

And HD video streams require *much* more bandwidth than audio (even DSD).

 

[Vincent Kars]

I'm afraid this has nothing to do with Eternet/WiFi or capacity.
UPnP is a pun on plug&play.
Like USB it has it's device enumeration. If a renderer reports not being able to play e.g. FLAC, The server will transcode FLAC on the fly to a format supported by the renderer e.g. MP3.
Likewise you might buy 24/96 Hi-res but Airplay is capped at 48 kHz.
In the past JRiver's media server had 320 kbs MP3 as default.
A server might as well apply some kind of DSP.
Etc, etc.
All of this has nothing to do with the capacity of the network or protocols like TCP/IP or even UDP. It is how device enumeration works out.
As a user you have a hard time to figure out what server and renderer have negotiated.
The transmission might indeed be as bit imperfect as possible like a server transcoding ALAC to AAC.

 

[audio_tony]

@Vincent Kars I wasn't responding to the UPnP part of your post (hence I only quoted the "streaming over a network is far more complex" part).

You make it (basic streaming) sound as though it's some kind of voodoo which it isn't. Products like MPD and Logitech Media Server for example, establish a client-server connection and the file(s) are simply streamed using the network stack, just like any other data is transferred.

There's nothing magical about it.

Just like we are able to view this forum - a client-server connection is established, and data is transferred. all of the 'transmitted' data is received by the client (web browser), regardless of whether or not any (IP) packet loss has occurred (within limits of course).

Obviously a technology such as UPnP has it's limitations with regard to media format conversions, but as stated above this was not the point I was discussing.

Additionally, with regard to your other comment;

By design.
Ethernet is packaged based. There is no guaranteed delivery time and no fixed route. The answer: a big buffer.

The capacity of a typical local area Ethernet connection (whether 100Mbps or 1Gbps) is more than adequate to transfer music files without the need for a buffer. If one finds a buffer is required, then there is likely to be a fault on the network.

Even a 32 bit .wav file will only use approximately 10Mbps which is obviously well below the limits of a 100Mbps LAN connection. Flac requires even less than this.

Therefore, "a big buffer"? I don't think so, as clearly there is ample bandwidth for streaming audio, even if the network has to retransmit every now and then.

P.S. I think you meant 'packet' based rather than 'package' based.

 

[antcollinet]

I'm afraid this has nothing to do with Eternet/WiFi or capacity.
UPnP is a pun on plug&play.
Like USB it has it's device enumeration. If a renderer reports not being able to play e.g. FLAC, The server will transcode FLAC on the fly to a format supported by the renderer e.g. MP3.
Likewise you might buy 24/96 Hi-res but Airplay is capped at 48 kHz.
In the past JRiver's media server had 320 kbs MP3 as default.
A server might as well apply some kind of DSP.
Etc, etc.
All of this has nothing to do with the capacity of the network or protocols like TCP/IP or even UDP. It is how device enumeration works out.
As a user you have a hard time to figure out what server and renderer have negotiated.
The transmission might indeed be as bit imperfect as possible like a server transcoding ALAC to AAC.

None of this is a problem with ethernet though. It is an issue of renderer capability - and or transmission protocol.

 

[audio_tony]

None of this is a problem with ethernet though. It is an issue of renderer capability - and or transmission protocol.

Which is exactly what I tried to point out in my two previous posts.