Certification process was outlined already. We should not expect to get progress updates in this forum, it would put @danny in uncomfortable position towards Devialet, he explained the reason a few times.
2 Likes
Boo 
Maybe just giving an update when Devialet provides the next iteration of certification is ok 
Is there already progress in the certification Devialet -raat?
@danny
A silly question to those who already know the answer but…in the context of this discussion and the certification process, what does “then we iterate” mean?
It would mean Roon is testing the integration with a new software from Devialet containing fixes for the bugs found in previous (failing) iteration.
Think about it as a car check-up with the particularity there will always be findings (100% on first try) and a finding may prevent to pursue the check-up (engine not running prevents checking CO2 at exhaust) so few/many iterations are needed to go through.
I have actually another question for @danny: Devialet IC board contains DSPs for extra signal processing power. Is it reasonable to assume current implementation of RAAT does not make use of those DSPs ? If it does (for example for Roon convolution filters) this is another magnitude of complexity in the porting and integration.
2 Likes
Yes, as all of Roon’s DSP is performed by the core not the endpoint.
1 Like
Thanks Carl, clear answer also featured on the Roon KB about RAAT. I would deserve a RTFM on that one
- Modest endpoint hardware requirements . This means endpoints don’t have to handle expensive DSP or content decoding–that will happen on the server. This means that many existing devices can add support for RoonReady without changing the hardware.
Was device owning the audio clock on Devialet AIR implementation ? I was having in mind the benefit of moving from UDP to TCP going to RAAT, now if they had designed the server to own the audio clock we will also eliminate clock drifting issues.
Not really, most computers only have modest clock crystals / circuits (they are not really designed for very high precision real time applications … the ones in [good] DACs are way better… hence for optimal sound quality the DAC itself should manage the timing not the server.
The only time clock drift is an “issue” is when zones are linked… ie more than one DAC … but the RAAT protocol deals with this by using one of the DACs [user selectable] as the master clock and the other endpoints in the group are adjusted as required to keep the music in sync.
1 Like
I think we are saying the same and I was not clear in my previous message…
My question was: In the Devialet AIR design/implementation, is the audio clock on the server side ?
If answer to that question is yes, then we will benefit from moving from AIR to RAAT design, as we will eventually have audio clock on device side which is the right thing to do to eliminate drift.
I’m pretty sure the audio clock is on the device when you’re using AIR.
That was also my assumption, now reading on the Roon KB that AirPlay was not designed that way and having in mind difficulties Devialet had to get Air decently working, I am not sure any longer.
Someone from Roon will know for sure, since they integrated AIR.
AirPlay is something completely different.
Still no progress? 
Refresh:
No progress update doesn’t mean no progress. It means we won’t get an update here. And believe me I am very impatient also to get RAAT running on my 440.
Exactly 
4 Likes
Devialet intended to deliver the update by Christmas - so there is just two more weeks to go. Keeping my fingers crossed
I’m also waiting for RAAT on my Devialet 440 Pro CI, but don’t know what the advantages are over Roon/Air apart from more grouping possibilities.
Being a program manager, I tend to differentiate an intent, a target, and a plan