Roon + Meridian suddenly starts playing

I had a few incidents of this as well earlier this year with my Sooloos setup MD600 + 818v2. All controls (ipad etc) were off, Roon core hadn’t been running for weeks, MSR in a drawer, etc. I noticed because the Control:Mac drew my attention to a message saying I had reached a skip limit on Rhapsody. I had an incident with volume ramping up by itself as well. More details here.

We’ve tracked down a rather complex set of steps that might cause this, and two separate bugs (one Roon’s, one Meridian’s) that were involved.

In order for this to happen, first some residue would have accumulated within the system, either as a result of network connections to going up/down or (more likely) zone transfer operations involving the Meridian zones.

Then, playback would have been terminated by putting the Meridian hardware into Standby, or switching to another input on an 800 series device without touching the transport controls in Roon.

That brings us to Roon’s bug: crashing while processing the “you’ve lost your source” message from the Meridian device and continuing playback. In all likelihood, Roon, forgotten, but still happily playing audio, kicks off radio mode.

Eventually, radio mode arrives at a track with a different stream format, which causes it to end the stream to the Meridian device and begin a new one.

The Meridian device says “Hey, new format. Uh oh, my source isn’t active. Better fix that” and sound starts coming out. If you have mostly CD quality content, and a relatively small proportion of High-res, this could easily take several hours or more.

(In the protocol spoken between Roon + Meridian, there are separate commands for “start an audio stream with format X” and “wake up the hardware and make sure that the ID41/MS200/whatever is the current source”–we do not expect the “start an audio stream” command to mess with source selection or pull devices out of standby, and we have confirmed that at the time of spontaneous noise, no “wake up” command was sent by Roon).

So Roon did bad by not terminating playback on standby or source selection. And Meridian did bad by waking up speakers as a result of a format change.

Roon’s side is fixed, and that fix will go out in the next release.

We don’t know whether Meridian will view their part in this as a bug or not. It’s conceivable that Sooloos depends on this behavior.

2 Likes

A few months ago I had Sooloos Tidal tracks starting by themselves at 03.00…deeply unpopular with DSP8k’s !!!
I reported it to HQ and I believe they eventually fixed it. Either in the core and how Tidal playback is triggered or in the zone firmware. I had zero detail like you have noted above.

I mention it in case there is anything in common with the second possible bug.

Thanks, @Brian. Interesting complexity. I often observe, when looking at a bug, that if somebody would write up this behavior in a spec, the devs would reject it as unimplementable…

But this brings up a related thought, a desired feature. In Sooloos there is good bidirectional communication: start playing Sooloos and the system powers up, power down or mute the system or change input and Sooloos pauses. And remote control integration. Everything bidirectional.

As you say, Roon does some of that but not all, with Meridian streaming. But not Meridian USB, and not the Geek Pulse USB. Is it generally possible to get state changes over most USB drivers? And command and control? For example, Light Harmonic says that their driver for the Geek allows level control from Windows but is implemented by sending commands to the Geek’s analog domain volume control.

To the extent that this is feasible with common devices, using industry standards for drivers and protocols, it would be great for Roon to support it. It is a very attractive feature.

And if it is not possible, can you drive the industry? And what about Roonspeaker? Of course you have command and control, but how bidirectional is it?

But this brings up a related thought, a desired feature. In Sooloos there is good bidirectional communication: start playing Sooloos and the system powers up, power down or mute the system or change input and Sooloos pauses.

Roon is supposed to provide equivalent functionality as Sooloos when paired with Meridian streaming. I’m not aware of any gaps, but that doesn’t mean there aren’t bugs somewhere.

Is it generally possible to get state changes over most USB drivers?

No. The problem really lies with the OS vendors–the audio APIs provide a very closed set of functionality, with no side-channel for handling control commands, so device manufacturers don’t bother to attack this problem 99% of the time.

A couple of companies provide proprietary solutions, often over a separate RS-232 connection to support integration with home automation systems.

I’m aware of a company or two that support separate drivers + system tray apps that sit alongside the USB Audio driver and allow for out-of-band control. I know of one company that are trying to push their second-driver-solution as a “standard”, but it hasn’t gained traction. We are keeping an eye on it to see where that goes–if it would get us fully synced volume controls with a handful of devices it would be worth the effort.

And if it is not possible, can you drive the industry? And what about Roonspeaker? Of course you have command and control, but how bidirectional is it?

The bulk of the network protocol is implemented by a lump of script delivered to the device at runtime (a la ChromeCast), so not only can we define the nature of communication, we can evolve it freely over time.

Infrastructure is in place for bi-directional volume, mute, source selection, transport buttons, and front panel displays. As long as we make sure that a device’s physical capabilities are exposed to the scripting engine as part of the initial integration, we will have flexible access to them.

This is a network-based technology, so none of this helps USB devices much…they’re going to be subject to the limitations of USB Audio drivers forever, but USB is on its way to being a legacy tech for audio distribution.

There is sound quality to be gained by separating media servers and devices. The number of USB ports in peoples’ lives is shrinking. Bridge products that can turn USB DACs into networked DACs are beginning to appear. Apple is making a laptop with the exact same port configuration as my phone, and anything cloud-driven is going to be network-based.

I think there are bugs. I’ll go through the experience systematically and document them.

Wrt USB, dang – but when you consider the original purpose of the audio API, it isn’t surprising or even blameworthy.

I agree with you on the network protocol. But it will be annoying for a lengthy transition: you may be right that USB will be replaced but at the moment we are in the process of improving USB audio. It will grow before it dies.

So we’ll have to deal with multiple remotes… Not me, because I’m Meridian, but most of us.

I definitely have noticed that I can go to standby from ms600 and playback continues. Will check on this later.