Getting a ’ playback parameters’ error when trying to use the Jriver ASIO driver with Roon.
I understand that the jriver asio driver shows 16 output channels and 0 input channels. Perhaps that throws off Roon?
By the way, not critical in my setup, but was hoping this would work a little better than the jriver wdm driver.
We’ve been discussing a similar issue with another user and just got some more logs from him yesterday.
They’re in a ticket in our bug tracker now, so hopefully this will be fixed for a future release real soon. Thanks for the report @rovinggecko!
Thanks @mike , nice to hear you got the relevant input already (keeps me in lazy mode ), assume you can reproduce, if you need more troubleshooting input you know where to find me.
Strange. I could swear I’ve seen that one work, and heard that other people are using it. The 16ch thing shouldn’t be an issue (Roon will just use 0 and 1).
I will make a note to take another look at it.
Having the same problem, any progress on it?
I spent some time digging into JRiver ASIO issues tonight.
From what I can see, in the current Roon software, 16bit content plays ok but 24bit content does not. This has been fixed, and the fix will be available in a future build.
I was also able to reproduce a “playback parameter negotiation” issue, but only when I’m switching back and forth between playing music in JRiver and Roon.
Basically in cases like this:
- Start Roon, pick the JRiver driver
- Start playback from Roon
- Start playback from JRiver
- Start playback in Roon again (e.g. use seekbar, press “next” button).
Looking at what’s actually happening, it seems like the JRiver driver is halfway disappearing on us, and Roon is getting confused. On one hand, it continues to consume audio samples from Roon, but on the other hand, if we attempt to start a new stream, it fails with a “device not present” error. My expectation would be that JRiver would send us a “driver reset” message at the moment when it stopped playing our content, indicating that the driver was no longer available for our use, but it doesn’t.
In any case, it’s possible to work around this situation and we have. The fix will be available in a future build.
If you guys are failing in other situations, please let me know so I can try them out and confirm if the same fix addresses them, or if there’s more to do.
Thanks @brian. Will see if i can get it to play 16 bit after a clean start to confirm.