Roon core is connected via USB to Yamaha R-N800A reciever. Yamaha Steinberg USB ASIO driver on Roon core used.
When Roon switches from one track to another and there is a sample rate change (either from 44.1 to 88.2/96 or from 88.2/96 to 44.1) Roon will stop playing and flash a message that it lost control of the audio device. I am always able to just press play and everything will resume as normal. If my queue is all one sample rate (either 44.1 or 88.2/96) then the error will not occur. It is only when going from one sample rate to another.
I read about this problem in the Roon Labs community. However, I don’t think it’s the fault of the Yamaha Steiberger usb driver, since the Foobar2000 program handles it perfectly. Foobar2000 switches to another sample rate without issue.
Reciever: YAMAHA R-N800A reciever via USB
Driver: Yamaha Steinberg USB Driver V2.1.4 for Windows 11/10 (64-bit)
Cabel: AudioQuest Pearl USBPEA01.5 1,5m USB 2.0 Type-A - Type-B USB
Device setup
Privat zone: No
Volume control mode: Fixed volume
Resync delay: 0 ms (I tried other settings as well)
External volume control: None
DSD: Nativ up to. 256
Max. sample rate: up to 384 Khz
Max. bit per sample: 24 bit
Use max hardver buffer size: yes
Use power-of-2 hardver buffer size: yes
Clock master priority: default
Sync adjusment: 0
Number of Tracks in Library
Verbatim Store N Go 500GB 53029, My music library is 180 tracks.
Description of Issue
On Tidal, I listen to songs from a playlist whose sampling frequency is not the same. When Roon switches from one track to another and the sample rate changes (either from 44.1 to 88.2/96 or from 88.2/96 to 44.1), Roon stops playback and sends a message that the audio device has lost control above. I am always able to press play and everything continues as normal. If the tracks are all at the same sample rate (44.1 or 88.2/96), the error will not occur. Only when switching from one sample rate to another.
I read about this problem in the Roon Labs community. However, I don’t think this is the fault of the Yamaha Steiberger usb driver, since the Foobar2000 program handles music tracks with different sampling frequencies perfectly, switching to another sampling frequency without any problems, as long as Roon Core is not installed on the laptop.
If Roon Core is also installed, Foobar2000 also displays an error during playback when the sampling frequency of the next track does not match the previous one.
In the Device Setup page above, the Resync Delay is set to 0ms - this means Roon is allocating no time between track buffers for the Steinberg to accommodate the new sample rate.
If you try 5ms or 10ms as a resync interval, does RoonServer retain control of the USB endpoint?
Another test - is the USB endpoint still visible in any other audio apps when this occurs?
This audio interface likely has a driver built for exclusive device control, similar to ASIO, since it’s built for pro and prosumer use. If you have a DAW open, or any other software outputting to the Steinberg via the driver, then RoonServer may be competing for control of the endpoint.
@rrwmd, Sonos endpoints connect via separate protocols than the Yamaha-driver based USB connection above. It sounds like you’re encountering a network dropout related - it’s worth posting your own topic thread in the Support section and including your network hardware details from the templatee for staff and Community to directly troubleshoot.
I tried ms 5 or 8000ms as a resync interval, but RoonServer doesn’t retain control of the USB endpoint.
If Roon is installed, also Foobar2000 displays an error during playback when the sampling frequency of the next track does not match the previous one. The Foobar2000 program handles music tracks with different sampling frequencies perfectly, switching to another sampling frequency without any problems, as long as Roon is not installed on the laptop.
No DAW other than Roon is running. I also tried without Foobar2000 installed.
Are you still seeing this issue at the present time, or has there been any change in behavior? If you are still seeing this issue, can you please share a new screenshot of the issue, as you did before of the affected track? We will then enable diagnostics mode to gather more details around the time of failure. Thanks!
Our Partners team has been working with Yamaha to isolate a bug that is consistent with your description.
At your convenience, please review my teammate @noris’s post above, as we’re hoping to capture an instance of this in the field to help guide our developer’s efforts.
Can you please let us know the exact local time + date + track when you next observe this issue, so that we can analyze the logging at the time of the issue? Thanks!
22 hours 36 minutes + 10.03.2024. + My Generation WHO (TIDAL)
When changing from 192kHz 24bit to 44kHz 16bit
The radio receiver has changed the frequency correctly
22 hours 38 minutes + 10.03.2024. + Twentieth Century Fox The Doors (TIDAL)
When switching from 44 kHz 16 bit to MQA decoder 88.2 kHz 24 bit (MQA 44.1 kHz)
The receiver also lost frequency.
22 hours 42 minutes + 10.03.2024. + Wish You where here Pink Floyd (TIDAL)
MQA decoder when switching from 88.2 kHz 24 bit (MQA 44.1 kHz) to 192 kHz 24 bit
The receiver has changed the frequency correctly
22 hours 44 minutes + 10.03.2024. + Behind Blue Eyes The Who (TIDAL)
When changing from 192kHz 24bit to 96kHz 24bit
The receiver has changed the frequency correctly
22 hours 46 minutes + 10.03.2024. + While My Guitar Gently Weeps The Beatles (TIDAL)
96kHz when changing from 24bit to 44.1kHz 16bit
The receiver has changed the frequency correctly.
22 hours 57 minutes + 10.03.2024. + White Rabbit Jefferson Airplane (TIDAL)
When switching from 44.1 kHz 16 bit to MQA Decoder 88.2 kHz 24 bit (MQA 44.1 khz)
The radio receiver also lost the frequency.
