Nice examples. Realy fits with the topic.
Regarding your previous claims, I think you will make us believe that a new CD you carry home with the Cayenne sounds better as if you would drive it home with the Honda.
That is an analogy that fits the topic.
4 Likes
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
514
You seem to be preoccupied by the fact that people disagree with you rather than what they say. Who is the naysayer? The person whose views are grounded in science and engineering or the person who denies such evidence?
I’ve been very clear about why I don’t think “router and Ethernet cables affect sound quality”. I’ve also made it clear what I think matters: well designed and engineered system components, speakers including their placement and so on.
For anyone who believes that it’s possible for an non-audiophile grade ethernet cable to harm the quality of the audio in their system, why wouldn’t you run everything over WiFi? That would eliminate all potential cable-related signal degradation, right?
2 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
517
Well, actually, I do, and it did. I was running a Raspberry Pi 3B+ over Ethernet, with USB out to my DAC, and getting dropouts and white noise sometimes. I switched it over to WiFi, and the problems disappeared. So, not necessarily a bad idea.
Having Ghz sender/receiver close to HiFi electronic is typically not a good idea, which is why in most cases ethernet twisted pair cables will sound better even if a little electronic noise slips through.
Yes, its the chorus or echo or whatever, far to the right at 1:11. Its from the “Decade of dreams” compilation, first tune (there is only one version on Tidal).
I sit 180 cm from speakers, in an armchair, so listening position is very fixed. Distance between speakers is 170 cm. The chorus at 1:11 is quite far to the right of the right speaker in my setup and room (which is acoustically well treated), and seems very sensitive to even very small differences in the setup.
In my case, that chorus is about 7 dm to the right of the speaker, or about 45 degrees (if straight ahead is 0 degree), but even small changes like removing the fiber I have between the ethernet switch and my HiFi moves that chorus towards the speaker.
I would guess the difference between an ethernet switch optimized for audio and a regular one would show a similar difference, but I don’t have one to test with so can’t be sure.
I have a Google mesh system, and I did have dropouts on Qobuz streaming, and this is gone as soon as I replaced it with a good Ethernet cable to my DAC.
Music over WiFi opens a similar can of worms. If every Access Point is directly wired with a switch, and you do not have many interferences, than it works absolutely perfect.
Every Access Point can have one or multiple spatial streams. On the 2.4 GHz Band one spatial stream can transport 65 Mbit/s on the 5 GHz it goes up to 450 Mbit/s. In theory, if you have an AP with 2 spatial streams you get a maximum of 130 Mbit/s on 2.4 GHz using 802.11n and 900 Mbit/s on 5 GHz using 802.11ac. On both bands you got more than enough bandwidth for your HiRes Music.
Now we come to the problems. WiFi is a shared media. Only one device can send data at the time. The bandwidth is reduced with the distance. You have interference (Microwaves, other APs) or you have mesh.
Using mesh halves the available bandwidth, because you have to get the data you send to a device you have to get first from an upstream AP. Using mesh in a perfect 2.4 GHz leaves you 65 Mbit/s usable bandwith.
As a rule of the thumb you can only use 2/3 of this bandwith for data. So we are probably down at 40 Mbit/s under perfect circumstances with mesh. If you use roon, you probably have a device like an iPad connected to the wireless, that also requires air time.
The numbers above are only valid for the best standard under good conditions. Connecting the devices with a lower standard like 802.11g it might work, with the very old 802.11b it does not.
The bandwidth required for music:
9 Mbit/s for 24/192
1.4 Mbit/s for 16/44
I have multiple APs spread over the whole house, everthing is optimised. I’m a happy WiFi user too.
@Peter_Bruderer’s got it exactly right – mesh wireless is definitely a compromise that reduces your potential bandwidth. All my “real” Roon endpoints are wired here – either 1Gbit or 10Gbit ethernet. But I still stream sometimes to my iPad over WiFi and I’ve never experienced any dropouts at any bitrate from my local library or from Qobuz.
9 mbits/sec should be no problem for any competent wifi network even when the microwave is popping your popcorn for this thread.
Ruckus ZoneDirector here with R710 access points (all gigabit wired). I wonder if I should connect my access points using audiophile ethernet cables.
Hmm. When I listen to that track, the backing vocalists are spread out (they are, after all, a chorus) from a position slightly to the left of the right speaker, to a fair bit to the right of the speaker. If I heard their voices emanating from one particular point, I would think there was something wrong with the presentation …
While I mostly agree with what you are saying, this is the part I have hard time with
I know real time kernel sounds cool and one might think it’s good for something (and it is, for something), the audio side benefits nothing from using it. It’s just something that lives as a folklore among tweakers. Modern hardware (even RPi) has so many time more than enough of resources to handle audio streaming that it’s just ridiculous. And especially with Roon. There is no need to even remove any unnecessary processes or anything, everything can run as it is and there is still a lot of bandwidth left for audio.
But what a real time kernel does it utilizes a real time scheduler. It just guarantees that the interrupt latency is less than some specified time in microseconds. That means that kernel will respond to external events in a certain time frame that is tighter than with other kind of schedulers. It still sounds kind of cool, but isn’t, in non real time audio case anyways. I mean it would be awesome for recording or monitoring, but not for buffered streaming.
In many cases real time kernel makes the performance of the machine worse overall and people that do not understand that should not be encouraged to use real time kernels. Now as I said, there are a lot of resources available for audio streaming, but if one wanted to optimize the kernel scheduler for audio use, I suppose it could be done, but real time kernel would not be the answer. It would have to be something that prioritizes audio and streaming related stuff. But then again it’s really not necessary so I guess that’s why no one has done it and the legend of real time kernel lives on.