Strange RAAT? behavior [Resolved]

Had an slight issue with Roon where i don’t think the behavior it exhibited was intended. Not sure if this is RAAT related or not but thought i would report it.

Setup is as follows a Gigabyte Brix running Windows 10 and Roon Server connected to the same router as my NAS which stores my library. I have a Sonic Orbiter SE connected to my DAC which is connected to my network via an Access Point. Control is through an android tablet. All are running the latest version of their respective software.

When i got home this evening i grabbed my tablet and resumed playing an album i was listening to this morning. As soon as i hit play Roon started immediately skipping through songs. By that i mean a song would quickly show on the play bar and less than a second later jump to the next without playing anything. Initially i thought something was wrong with the tablet and then noticed that my DAC and Amp were in stand by. I was unable to pause what was playing on the tablet as it was skipping to fast and had to fire up my PC to do so.

I turned on my dac and amp, hit play, and the same behavior persists. I remoted into the Brix to restart Roon and the same behavior persisted. Finally i restarted the sonic orbiter and it that seems to have corrected the issue.

Im guessing the cause was hitting play with the DAC off as when i tested it a second time to confirm i noticed this popup briefly:

I didn’t notice it this morning when i assume i put my dac and amp in standby. Subsequent testing showed that it only popped up once after the server was restarted. More specifically I can restart Roon Server, turn off my DAC and it will pop up. If i turn it back on before hitting play everything is fine. At this point i can turn off the DAC whether the music is playing or paused and get one of two results. Either it keeps playing at normal speed, according to the wave bar or it paused the music. If i restart the server and hit play with the DAC off it freaks out again.

Im not sure if this is an issue with Roon, RAAT, the Sonic Orbiter SE, or my DAC but would it be possible to change to behavior when this occurs so that it issues another popup or error message rather than skipping though the songs? Apart from being confused trying to stop playback to try and rectify the situation wasn’t easy.

Yeah, I think I know what is happening.

Our software is written with the assumption that the device will start/stop the RAAT server when the audio device is plugged/unplugged.

By design, when you’re unplugged, there should be no zone visible in Roon.

It seems like it’s not doing that. I’ll help them sort it out.

1 Like

Thank you, had the same issue this morning.

No zone visible would be perfect. Thank you.

Call me a cynic, but this seems to be a fundamental issue with these Linux based slim devices. That is, they do not know when a connected audio device is actually on or not. It is not just Sonore, but RPI 2 (and even a Linux daemon running on Mac Mini) also when using any form of NAA. In simple terms, I am assuming the RAAT is a very sophisticated NAA that allows deeper control from Roon core, but if the under-lying OS of the slim device does not know that an input has been changed or switched on / off then this is a big user issue. Isn’t it?

If these slim devices are going to take off for the broad use of family members and guests rather than the twiddling audiophile, this has to be sorted. IMHO.

I might add that I really want the Sonore microRendu, but dropping connections from attached DACs could be a show stopper for me.

1 Like

It’s not the issue with Linux based slim devices, it the issue with any network to USB bridge (so even the Auralic Aries, which is not so slim, has this issue). There isn’t enough information flowing over the standard USB audio protocol to do standby and power status updates.

Standalone networked Roon Ready endpoints (ones that don’t bridge to USB endpoints) don’t have this issue, as RAAT allows for the custom commands.

Thanks for the clarification @danny I’m not sure it helps though, a fair few of these slim devices are designed to output via USB (the microRendu will be only USB), they are marked as RoonReady, yet they cannot tell when a USB connection is live or not? The Aries is Linux based, is it not? Is bridging to the USB unresolvable or do the suppliers of these devices and NAA’s have to look into this?

If the manufacturer actually powers down the USB, then it is possible, but then it’d be impossible to get Roon to power it back up. What you want, is power off to feel like it’s not even plugged in, and you want standby mode that can be toggled.

Well I do know that the Devialet’s initiate a ‘handshake’ every time you switch to the USB input (because you can disable this in the Dev’s settings) but it would appear the Linux based NAA’s do not listen out for this, I guess they cannot because they have dropped the connection on their own device’s USB. The Devialet’s go into standby mode or low power state as they like to call it, so they are not fully switched off.

It follows that the NAA has to respond to this handshake, question is whether this is do-able? Devialet’s apart, if these network devices are going to gain popularity, they really need to cope with the simple act of switching inputs, or bringing out of standby on the downstream DAC. It’s pretty fundamental I would think.

It also depends on your DAC. I have one that keeps the USB interface up when the unit is powered down and the SOSE has been rock solid, so has another Linux based NAA I use. My headphone DAC, the connection does drop between long periods of inactivity.