Yes, a poorly implemented wifi setup may suffer more latency/throughput issues than a robust ethernet connection, and that might impact SQ. On the other hand, in theory a well implemented wifi setup might actually sound better than an ethernet connection given it’s inherent electrical isolation.
edit: my own personal opinion is that one won’t hear a difference given all of the electrical noise from the DSP units and SMPS power supplies in the LS50W speakers. In which case, ethernet might just be more reliable.
I had no idea it was a religious question but it sure sounds like it is. Everyone seems to agree that ethernet is more reliable because that is pretty obvious and wifi depends on your home wifi network and setup which for a lot of people is pretty poor.
We also don’t know the details of the internals of the Kef’s i.e. what is on the internal side of the wifi interface. One would hope they have that covered but there is awful lot of stuff in there.
When I say ethernet (which I am very familiar with from a data, voice, and video but not music audio perspective) of course I’m not talking about just the physical layer but the protocols it uses as well. UDP is not error correcting by the way. It does use a checksum for error detection but can’t really do anything about it. So I’m not too sure how much value there is in it as a backup.
I don’t get why you say at the level of music data though. What do you mean by that? It sounds contrary to some things I have read recently about music audio over ethernet but don’t have on hand at the moment. As far as transport goes and packets of data I don’t see why music isn’t the same as anything else but maybe it is different.
RAAT is really interesting to me. Big kudos to Roon for coming up with it. I’d like to understand more about it as well as how much of RAAT functionality this integration will use.
As far as SQ of one type or another there are so many factors I would just go with what sounds better and what works in your particular case. I’ll use ethernet
On another note Kef shipped my replacement speakers today and it looks like they arrive next Monday. So it took them three days from the time they received my broken ones to send new ones. Not too bad I suppose I’ll just be glad to have them back.
coming from the SB world, in my experience, ethernet has sounded better. this may be squeezebox specific, but it’s been repeatable with different Squeezeboxen (transporter and touch) and analog or digital connections to pre/dac.
i have no opinion on why this might be so, just what my ears tell me.
I suspect that if Roon is reporting the signal path as lossless on wireless there is no drop in quality actually happening. It should be superior to any wired connection which can suffer EMI/jitter issues. Possibility there is some extra EMI generated on the endpoint if there is extra processing overhead for the wireless connection but I doubt that would be an audible issue.
Now, if packets are being lost in a UDP transmission that would be one thing, but I imagine Roon would be able to detect that and report it as a lower quality connection. Would be great for someone from Roon to jump in here to clarify.
People like Ethernet because it’s more reliable. If you have STABLE wifi connection, certainly it doesn’t affect SQ. Protocols like RAAT isn’t like youtube who might downgrade the quality to adapt your network status, they make sure bit to bit transmission as a priorty. Even if your wifi connection is poor, it becomes slow(might cause stuttering) but does not alter the content it sends. Even while wifi is comparably unreliable or slow, it is mostly sufficient for HQ sound, except for crazy stuff like 512 DSD.
Personally, I hate wires, so I’d invest to optimize my wifi connection. It’s very achievable with today’s technologies. And cheaper, “HI-TECH” stuff is much cheaper than HIFI stuff.
Technically, I believe RAAT requires functionality in the firmware of the device itself - essentially a server of sorts to run on the LS50 which would expose an endpoint to Roon to broker and process traffic by using an SDK Roon provides.
That’s not part of this upcoming implementation, it’s all Roon. We know that the LS50s already have a streaming protocol implemented but one that Roon feels is insufficient in some ways… my impression is that will still be used to some degree with some additional functionality on top to overcome these problems. The downside is it will be more data intensive than it would be if it were simply an RAAT integration, which I believe it the reason to limit to one set of speakers.
Not judging anyone/anything, but it is well written here. If only KEF had interfaced with Roon Team before closing ls50w interface specs on firmware, hardware S/W etc, to make it any easier for RAAT integration. Eventually it will be some form of Roon interfacing but not full ON endpoint or RoonReady etc.
Lets allow Roon team to work their bit and come up with some sort of solution. My hopes are high but ready for anything.
While I agree it would be nice if Kef had interfaced w/ Roon, I don’t know if this is particularly fair to Kef .- there’s a good chance they were done w/ primary product development before Roon/RAAT even existed on the market… the LS50W wss announced a year ago, Roon/RAAT is barely more than 2 years old. If they contracted out their software dev (likely as it’s not their core competency) they wouldn’t really have the option of being all that agile… it could have driven R&D costs up considerably, pushed the launch date out by months, etc, for a new market player who’s performance was not evident yet.
In any case, the solution they have is here as reported by Darko and demonstrated by Kef last weekend at CEDIA. They’re just working out the final kinks before it lands in an update we should be getting in a week or two.
There’s no significant difference in terms of data transmission (error correct or data format translation) between any IPV4/IPV6 connection, be that over wired or wireless connections. RoonBridge uses TCP now and that’s all there is to it.
I think the reason for the lower-than-we’d-like adoption of RAAT in hardware products is the fact that it’s actually a very smart little bugger. If I understand correctly, it is in fact an on-the-fly data transmission protocol, in the sense that at the beginning of a connection between the server and the rendering point, a piece of code is sent to the client (rendering point) that describes how the following music data transfer should proceed. Again, if I am not mistaken, it shares this concept with Google’s Chromecast, and, as a software engineer, I have to say this is a brilliant and very daring approach. However, the ability to implement such a wonderfully flexible and upgradeable protocol is less than trivial. Yet again, if I am not mistaken, and for those more technically inclined, I think what happens is that an actual piece of Lua code is being sent from the server to the client that contains the details of the transport used (TCP, UDP), the message formats, and quite possibly other things. The approach is really quite novel, as opposed to settling on a specific transport, specific framing formats, allowing for some variance (“reserved” fields anyone?) and then hoping it will be sufficient for the time to come.
Not disagreeing with your position. Personally I struggle with wireless not in terms of reliability but actually buying it sounds as good as through a good wired ethernet network. No science behind my thinking at all and its not like i’ve really bothered to sit down and compare. My sense is from the times i’ve used it it does not sound as clear so i steer away from it.
I’ve seen it said a couple of times in these forums that besides the fact bit perfect delivery is still what you get the noise floor is higher on a wifi connection.
Our UDP was reliable as well, it just didn’t play as nicely over the network with other traffic. TCP has congestion control that allows it to play well with others. While we did implement reliability, we did not implement congestion control.
With 70+ partners now having released or making products, I wouldn’t use the word low at all.
The delays in RAAT support often have to do with long product cycles, lack of in-shop ownership of the network boards, and lack of expertise in the company related to anything network related.
KEF was in a misaligned product cycle when they wanted to do something with Roon. We wanted to support them anyway due to the LS50W being a great product with serious user adoption. The Devialet Expert + AIR was the same.
You do. Your understanding is very accurate.
This is 100% accurate. 1 final kink left that affects a very small subset of users, but will be a support nightmare if it gets out the door.
That is interesting, I guess the WiFi chip inside KEF is more noisy than the Ethernet connection is, despite that Ethernet might bring some noise from the other end.
So Roon will need to leverage/use whatever protocols the LS50W firmware currently supports over ethernet/wifi. Possibilities include:
DLNA/UPnP: Amongst other issues, Kef doesn’t support gapless playback for one thing, and I don’t think anyone thinks Roon is going to use that.
Some other undocumented protocol that Kef has provided to Roon and which Roon is leveraging, incomplete or not (eg. Kef has been working on support for Spotify or ?)
Tidal: Roon could knowingly hijack the Tidal API that Kef now supports. The KEF firmware has it’s own client side Tidal api implementation (and there are a number of open source, available Tidal api implementations out there). If Kef has provided to Roon the API that the Kef App uses to control the KEF tidal service in the speakers, then there is no reason that Roon could not implement that API as well. So the RoonServer sends commands to the LS50 that mimic the current Kef tidal app interface but with an endpoint that points back to the local RoonServer instead of Tidal’s servers … and then the LS50 uses the tidal api to magically stream music from the RoonServer. Absolutely crazy … or not?? I don’t know if Tidal has any IP over the actual API/contract that it has published, nor if it cares. The ‘final kink’ might be problems with users with network setups that don’t play nicely in this scenario eg. direct ethernet bridges and such. But now I am just taking shots in the dark!
