Another review of a streaming end point, from Bel Canto.
@Danny, you expressed contempt for uPnP. Care to discuss this further? Because there are lots of these devices, and it is attractive not to have to put a computer everywhere…
Sorry, forgot the link, at AudioStream.
@AndersVinberg: We are working with Bel Canto to get RAAT into their devices.
Our contempt for UPnP basically comes down to a few things:
- UPnP requires codec support on the endpoint, therefore making different endpoints support a different subset of whats out there. This also puts a burden of patent licensing on the manufacturer.
- UPnP has no good solution for streaming proprietary/unsupported/new formats
- UPnP creates an ecosystem of lowest common denominator support
- UPnP lacks “a brain”, like the Roon or Sooloos Core, so it cant do intelligent things like Swim/Radio, normalization, crossfading intelligence, those pretty waveforms in the seek position, etc…
- UPnP leads to a pretty foul experience. Spreadsheets and file management is not how music should be experienced. We haven’t seen a good user experience with UPnP, ever. The HiFi dealers agree, and only put up with UPnP because they must. It was clear that UPnP was made by/for endpoint manufacturers, and not user experience creators. Our party line is that “UPnP leads to Twonky”. You can put lipstick on that pig, but fundamentally, without a brain, you have Twonky like experience.
OpenHome has the exact same issues, and although they are fixing a lot of the low hanging fruit, we believe the architecture is fundamentally wrong.
Airplay got the above right. By streaming PCM, and with Apple certifying their implementations, Airplay devices are quite robust and always provide a great experience. It doesnt matter what new format or stream the endpoint supports, as long as the source can turn it into PCM. The experience is in the hands of the brain, not the renderer.
Songcast is similar to Airplay in this regard.
Unfortunately, both Airplay and Songcast have two fundamental problems related to sound quality. One is limited format support (no DSD) and the other is that the clock is driven by the source, instead of the receiver (the endpoint surely will have the best crystal in the room).
We solve these problems with the Roon Advanced Audio Transport (RAAT) protocol. The 100+ manufacturers we’ve spoken to, including Bel Canto that you mention, are loving our solution. It puts the audio in their hands, and the experience control in ours. It compromises nothing for quality, and puts very little burden on the manufacturer. It also allows for expansion, while never creating a lowest common denominator experience.
We are confident UPnP support will start being second tier in the world of HiFi manufacturers. This is why you are having to deal with “computers” right now. We all hate computers too. If you want no-compromise high quality audio, you need top-end electrically isolated devices. General purpose computers are solving a totally different problem. RAAT aims to solve that by working with every hardware manufacturer, as well as providing multiple DIY solutions ranging from turnkey Android/iOS app to a bit more involved RaspberryPi builds.
19 Likes
I think you’re being a little disingenuous to Songcast / Linn here. The idea is that my primary source (A Linn Klimax DS/1) has quite a good clock thank you, and my lesser receivers (in other rooms in the house - a selection of Linn Sneaky DS’s) can take advantage of that.
I agree that I can’t play DSD, but I’ve never found that a sound quality issue.
Rik
I think you are wrong about how Airplay manages audio Clock. It isn’t source that drives the clock. Airplay doesn’t use s/pdif or similar protocol. It is a network based protocol and lays on top of TCP/IP.
1 Like
@Rik, @Bitperfect in both cases of Airplay and Songcast, the sender sends packets to the receiver at a constant rate, based on the clock inside the sender. The receiver reads these packets, and plays them using the clock inside the device. You’d think this was perfect quality, but let’s do a simple thought experiment:
Let’s say your Mac’s clock is 10% faster than your DAC’s clock. Then, whether it is Roon, iTunes, or whoever, sending CD quality data over Airplay or Songcast will send 48510 (10% extra) samples every second instead of 44100.
There’s no way in these protocols for the receiver to say “slow down! you’re sending data too fast”, so the receiver has to deal with this situation somehow. It could drop the extra 4410 samples, creating one big glitch, or perhaps many small glitches over the course of a second. It could perform an Asynchronous Sample Rate Conversion (ASRC) in software or hardware, taking a quality hit in the process, or it could bend its internal clock to match the clock of the source. Clock bending is the highest quality option of the above, but it doesn’t stop the music from playing 10% too fast.
This is what we mean by the clock being owned by the source in these protocols.
@Rik, In the case of your Linn devices in a linked situation, the clock is owned by the DS, but that’s because you are still using UPnP instead of Songcast to get media into the Linn DS. If you used Songcast, you’d be at the mercy of the source’s clock. Also, if the clock in your Sneaky DS’s deviate from the master clock in the DS, it’ll have the same problem of having to conform to the master clock. This is a fundamental problem when linking zones in any system, since no two clocks will ever be in perfect sync. In this situation, bending the secondary clocks is the best option.
So in a purely Linn hardware driven environment, where the stream is driven by a high quality clock that you trust, there is little quality concern. That’s not the situation when source like Roon, iTunes, or the Linn Songcast audio driver interact with a protocol like Songcast or AirPlay, since in those cases, a computer is clocking out the stream. Since there’s no way in the Songcast protocol to recover the high quality clock from your master device, the computer’s system clock is used, and all Linn devices must compensate for any deviations from perfect using one of the techniques mentioned above.
The right solution here is to allow the sender to synchronize it’s sending to the receiver’s clock. This can be done through clock feedback from receiver to sender, or it can be done via many different flow control mechanisms. RAAT does this.
You can read about the Songcast protocol here: http://wiki.openhome.org/wiki/Av:Developer:Songcast:Ohm
Airplay doesn’t have an official published protocol spec, but you can read about a reverse engineered spec here: http://nto.github.io/AirPlay.html
2 Likes
If we’re playing though experiments consider a single Roon Core with two RoonSpeakers, one clocking slightly fast, the other slightly slow. [As the Roon protocol isn’t public, we’ll have to make some assumptions.]
I wan’t to have a synced ‘Party’ mode where all the speakers in the house / zone play the same music. But both RoonSpeakers are the 'master. So do you clock slightly fast or slightly slow?
You will have to elect one of the two (or more) RoonSpeakers are the boss, who will then (presumably) push "go a bit faster’ / ‘go a bit slower’ messages to the other RoonSpeakers. So all RoonSpeakers are equal, but some are more equal than others.
The only (simple) solution is something akin to the Linn SyncLink protocol or some other the ntp like protocol. But even then you are going to come across problems like Byzantine Generals and Paxos really is very hard to implement.
I look forward to reading the RoonSpeaker protocol (if I’m ever allowed to that is)
Rik
As I stated:
This is a fundamental problem when linking zones in any system, since no two clocks will ever be in perfect sync. In this situation, bending the secondary clocks is the best option.
Also, only one can be boss… that’s why he’s the boss 
Assuming the network protocol can properly flow control, NTP gets you only half way to playing in sync. NTP enables the devices to know far off they are, but it doesn’t do anything to get the samples back in sync. There are 3 ways to do this: Bend the clock, bend the samples (ASRC), or drop/add samples to sync back up.
@danny Without giving any secrets away, what does an endpoint manufacturer have to do to be ‘Roon certified’, is it simply some code work in the firmware for their units?
It seems that you guys will be pushing RoonSpeakers big time in the near future, and all power to you, I hope it revolutionises the user experience on top-end hardware, where sadly the user control is greatly lacking.
It may be obvious, but how will the licensing work (again without divulging secrets), will the endpoint manufacturers license Roon on behalf of their users, or will the user have to make his own arrangements regarding Roon? Or a mixture of both, depending on the manufacturers commitment to Roon, and vice-versa?
@allenbretao, I wrote about this here:
As for licensing, we’ll figure that out as time goes on. Right now, we are working with select partners we feel will both benefit from RoonSpeakers and where we’d benefit from their audio expertise. RoonSpeakers is to be built into the device. If users don’t use Roon, they won’t know anything about RoonSpeakers. If they do use Roon, they will take advantage of the benefits RoonSpeakers provides.
Many thanks @danny, given the talk about separating the core from the endpoints I am slightly in a state of flux, and chomping at the bit to get it figured as to where I go. Currently running Roon on a MacMini core directly (USB) attached to my Devialet 200, but there are quite a few possibilities here. I would like to move the Mac to purely server duties as a core away from the system and that will open up the choice of endpoint (potentially the Devialet could become an endpoint I suppose). I have one or two in mind, but not if they do not support RoonSpeakers in the future. Have to have Roon now 
I share the same disdain for UPnP and a big reason why I have moved away from Naim. Trouble is so many of the potential endpoint manufacturers, especially at the higher end let’s say, seemed to be locked into UPnP in one way or another.
So really looking forward to seeing who is getting on board with you guys, exciting times ahead.
1 Like
A post was split to a new topic: Can I play wirelessly to my Oppo?
Hi,
Just to stir the soup Apple AirPlay is also limited by sample rate. You may get a bit depth of 24-bits but from mixed reviews/testing from the people at Digital Trends, I believe the maximum sample rate is 44.1KHz or possibly 48KHz.
While there maybe contempt with UPnP/DLNA, the contempt is really directed at the point the digital world meet the Analogue i.e. the DAC. Until true high-end Network Streamers are supported that samples at rates approaching 192KHz, you only have half a solution. The hard truth is: Digital is easy compared to Analogue which is really the reason for contempt.
Jason
Just trying to find a solution to a primo piece of equipment in an Ayon S-5
Holy Necromancer
1 Like
Reads like a post from 1980 or so, “until true high-end Network Streamers are supported that samples at rates approaching 192KHz”
1 Like