Introducing Olympus & Olympus I/O - A new perspective on modern music playback

[2ndLiner]

The grand cat approves


View attachment 162157

Awesome Taiko ad!

 

[ray-dude]

Long time Taiko fan

 

[John T]

Awesome Taiko ad!

TAIKO FOR THOSE WHO GET ALL THE P**SY!

Edited for forum decorum.

 

[John T]

Long time Taiko fan View attachment 162158

Emile may have slipped a little catnip in...

 

[nonesup]

The other day I was watching a YouTube video of Miles B Astor with his pair of Zellaton Plural Evo speakers and two monoblock amplifiers, I think Goldmun. A cat was on one of the amplifiers, then jumped onto the other, and finally got off and started moving around the back of one of the Plural Evo speakers. I couldn't help but wonder what would happen if, as the cat moved, it disconnected one of the speaker wires and that wire made contact with the other pole.

 

[DW101]

A little late to the party, but…

 

[John T]

Look Familiar Dave?

 

[DW101]

We have two gingers, Bunny (pictured) and Boogie, they are my “autonomous biological sound diffusing units”

 

[joet]

While I can't give credit for this to a cat or Oscar, my dog, the Roon issue of "losing control of the audio device" seems to have abated. On the advice of my amp manufacturer, I've been running music on a loop in Roon. For the past 36 hours I've noticed Roon hasn't stopped on its own. I don't know what changed, I wasnt asked to authorize an update. However, prior, the Roon app was frequently crashing so I reinstalled it.

 

[John T]

While I can't give credit for this to a cat or Oscar, my dog, the Roon issue of "losing control of the audio device" seems to have abated. On the advice of my amp manufacturer, I've been running music on a loop in Roon. For the past 36 hours I've noticed Roon hasn't stopped on its own. I don't know what changed, I wasnt asked to authorize an update. However, prior, the Roon app was frequently crashing so I reinstalled it.

Did you see Emile's post regarding playing music or just having it on accomplishes the same thing?

 

[joet]

Did you see Emile's post regarding playing music or just having it on accomplishes the same thing?

I did, thank you for the heads up.
This was necessary for the amps, not the Olympus. The manufacturer said they needed to be on full power about 4+ days after being cold for a while, and that playing music would speed up the process. Also, sometimes "Roon losing control of the audio device" happened while listening, so it was annoying that way as well.

 

[joet]

While I can't give credit for this to a cat or Oscar, my dog, the Roon issue of "losing control of the audio device" seems to have abated. On the advice of my amp manufacturer, I've been running music on a loop in Roon. For the past 36 hours I've noticed Roon hasn't stopped on its own. I don't know what changed, I wasnt asked to authorize an update. However, prior, the Roon app was frequently crashing so I reinstalled it.

Spoke too soon, just happened, for the firet time in afew days, while listening.

 

[dminches]

Spoke too soon, just happened, for the firet time in afew days, while listening.

I have had occasional stoppages as well.

 

[StefanK]

I have had occasional stoppages as well.

Well, I finally got around to have a nice longer listening session and noticed a very strange stopping situation while playing flac 44/16 from my NAS.
Music suddenly stopped, but the Roon play indicator was still progressing and there was no error. I tried to scroll back and forth within the song ,but that had no effect. So then I tried to play another track from the same album. This also did not work. I mean Roon was showing that all is good and playing, but I had no sound coming out of speakers.
Then I tried to switch to an internet radio in Roon, which also did not solve the issue.
To be sure Roon is not messed up I then played the same internet radio into my iPad and that work immediately.
Then again I tried to play via Lampizator and this time the music finally started to play from the speakers.

There was no 'Critical' error in the Roon logs. Only the following warnings:
12/01 11:36:15 Warn: [remoting/brokerserver] [initconn 192.168.25.133:64510=>192.168.25.20:9332] failed: System.Exception: incomplete receive
at Sooloos.Broker.Distributed.InitConnectionV2.Go()
12/01 11:36:45 Warn: [zoneplayer/raat] Error during streaming: System.NullReferenceException: Object reference not set to an instance of an object.
at Sooloos.Broker.Transport.RaatZonePlayer.<>c__DisplayClass31_0.<_StartStream4>b__1()
12/01 11:37:55 Warn: [zoneplayer/raat] Error during streaming: System.NullReferenceException: Object reference not set to an instance of an object.
at Sooloos.Broker.Transport.RaatZonePlayer.<>c__DisplayClass31_0.<_StartStream4>b__1()

And as I was typing this I had another stoppage. This time i was able to resolve it just by pressing play since Roon was actually showing the track in paused state.

Here are the logs for the second stoppage:

12/01 11:57:22 Warn: [zone Lampizator] Track Stopped Due to LostEndpoint
12/01 11:57:22 Info:
--[ SignalPath ]---------------------------------------------
SignalPath Quality = Inactive
Elements:
------------------------------------------------------------
12/01 11:57:22 Warn: inactive signal path : (
12/01 11:57:22 Info: [zone Lampizator] OnPlayFeedback StoppedLostEndpoint
12/01 11:57:22 Warn: [raat_ll/client] [Taiko XDMI] failed to connect(0) Cannot access a disposed object.
Object name: 'System.Net.Sockets.Socket'.
12/01 11:57:28 Warn: [remoting/brokerserver] [initconn 192.168.25.133:64558=>192.168.25.20:9332] failed: System.Exception: incomplete receive
at Sooloos.Broker.Distributed.InitConnectionV2.Go()
12/01 11:59:46 Warn: [rnet/RnetJsonClient] failed to connect No connection could be made because the target machine actively refused it.

 

[Taiko Audio]

Unfortunately, this isn’t strange at all, it’s an ongoing issue that has been affecting roughly 10% of our customers for quite some time. We have no visibility into how many users of other brands are experiencing the same, but a new thread with these symptoms appears on the Roon support forum almost daily, on top of the long-running ones.

What makes this such a difficult problem for Roon (and for us), I suspect, is the intermittent nature and the apparent dependency on local environmental factors. For example, here in Oldenzaal it has only occurred twice in over 2 years, June 11th and July 17th (2025). Outside of those two events, every Olympus runs uninterrupted for five days straight during burn-in/QC. We even went as far as exchanging entire servers, only to find that this was a complete waste of effort: the “faulty” units played flawlessly here, while the replacements displayed the same behavior once installed at the customer location.

Since Roon has been working on this for a long time, we’ve started our own parallel project to offer a practical workaround: increasing buffering/track caching for users who are impacted. We’ve also built a fully duplicated Linux environment, allowing us to run Roon OS variants such as ROCK. Notably, users running ROCK report similar issues, so it’s clearly not tied to a specific OS.

Still, the more parallel approaches we develop, the more options we’ll have to intervene effectively, ideally without compromising the advantages XDMI has over other protocols.

 

[jbrrp1]

Unfortunately, this isn’t strange at all, it’s an ongoing issue that has been affecting roughly 10% of our customers for quite some time. We have no visibility into how many users of other brands are experiencing the same, but a new thread with these symptoms appears on the Roon support forum almost daily, on top of the long-running ones.

What makes this such a difficult problem for Roon (and for us), I suspect, is the intermittent nature and the apparent dependency on local environmental factors. For example, here in Oldenzaal it has only occurred twice in over 2 years, June 11th and July 17th (2025). Outside of those two events, every Olympus runs uninterrupted for five days straight during burn-in/QC. We even went as far as exchanging entire servers, only to find that this was a complete waste of effort: the “faulty” units played flawlessly here, while the replacements displayed the same behavior once installed at the customer location.

Since Roon has been working on this for a long time, we’ve started our own parallel project to offer a practical workaround: increasing buffering/track caching for users who are impacted. We’ve also built a fully duplicated Linux environment, allowing us to run Roon OS variants such as ROCK. Notably, users running ROCK report similar issues, so it’s clearly not tied to a specific OS.

Still, the more parallel approaches we develop, the more options we’ll have to intervene effectively, ideally without compromising the advantages XDMI has over other protocols.

Glad to hear that Taiko is working on this issue, Emile. I guess I'm one of the 10% who suffers this issue. I get the complicated stop that @StefanK describes above once a week or so. I get the simpler stoppage that one can restart by hitting Play every other day or so. I almost never had this with the Extreme (a handful of times in a few years maybe?), so if it's a Roon issue, it's pretty odd that it happened to coincide very precisely with my change from Extreme to Olympus + I/O in early March of this year. But coincidences happen.

This is very aggravating when one is in the musical flow. It's downright embarrassing when it happens while playing music for a guest.

 

[Taiko Audio]

Glad to hear that Taiko is working on this issue, Emile. I guess I'm one of the 10% who suffers this issue. I get the complicated stop that @StefanK describes above once a week or so. I get the simpler stoppage that one can restart by hitting Play every other day or so. I almost never had this with the Extreme (a handful of times in a few years maybe?), so if it's a Roon issue, it's pretty odd that it happened to coincide very precisely with my change from Extreme to Olympus + I/O in early March of this year. But coincidences happen.

This is very aggravating when one is in the musical flow. It's downright embarrassing when it happens while playing music for a guest.

That’s not odd at all, though it is difficult to explain without going into deep technical detail. The vast majority of Extreme owners use USB. USB is essentially a local, point-to-point connection with very large buffers, designed to be “bulletproof,” and frankly not very sensitive to sound-quality variables. It behaves like a directly attached device pulling data locally.

XDMI looks similar on the surface, physically local, but functionally it’s a completely different class of device. It’s a remote endpoint with its own processor, memory, storage, and clock domain. If you compare it to how you were using the Extreme before, XDMI behaves far more like a networked component than a local USB device.

Because of this, the link between Roon and XDMI is subject to the same constraints and fragilities as any networked endpoint under RAAT: network jitter, switching behavior, packet timing, interrupts, and local environmental factors. That’s where the variability comes from.

So if this still feels counter-intuitive, the key point is: USB and XDMI are fundamentally different. USB is local and heavily buffered; XDMI is remote and RAAT-dependent. And if you look at Roon’s own support forum, nearly all the problems people report involve networked endpoints, not USB.

 

[cat6man]

That’s not odd at all, though it is difficult to explain without going into deep technical detail. The vast majority of Extreme owners use USB. USB is essentially a local, point-to-point connection with very large buffers, designed to be “bulletproof,” and frankly not very sensitive to sound-quality variables. It behaves like a directly attached device pulling data locally.

XDMI looks similar on the surface, physically local, but functionally it’s a completely different class of device. It’s a remote endpoint with its own processor, memory, storage, and clock domain. If you compare it to how you were using the Extreme before, XDMI behaves far more like a networked component than a local USB device.

Because of this, the link between Roon and XDMI is subject to the same constraints and fragilities as any networked endpoint under RAAT: network jitter, switching behavior, packet timing, interrupts, and local environmental factors. That’s where the variability comes from.

So if this still feels counter-intuitive, the key point is: USB and XDMI are fundamentally different. USB is local and heavily buffered; XDMI is remote and RAAT-dependent. And if you look at Roon’s own support forum, nearly all the problems people report involve networked endpoints, not USB.

is this only a streaming issue, or does this also happen in some systems with local files/NAS?

 

[Taiko Audio]

is this only a streaming issue, or does this also happen in some systems with local files/NAS?

It can happen with any source. It’s counter-intuitive, but low-level mechanics like interrupts don’t stay isolated, they influence the entire “network” path.

 

[dminches]

is this only a streaming issue, or does this also happen in some systems with local files/NAS?

I rarely stream and it occurs on my system periodically (when I am playing files from my NAS).