More > JRiver Media Center 28 for Linux
Troubleshooting the Steinberg UR824 with JRiver on Linux
mwillems:
--- Quote from: bob on February 03, 2022, 01:42:38 pm ---Also, I have a dragonfly that works fine with S24_3LE which works fine.
Is it distorted if you use internal volume control on linux and turn down the volume?
--- End quote ---
Yes the distortion volume seems unrelated to the volume settings, I've tried both internal volume and system volume at various settings and the distortion is always very loud.
Just now I stole a few minutes with the interface and setting the PCM format to auto, I couldn't seem to get JRiver to playback at all (even with the distortion), I just kept getting playback errors. I've attached a log below with two tries and errors. It looks like maybe the device isn't allowing JRiver to open it with 6 channels? I guess that jibes with what alsacap seems to be saying (that the device supports between 12 and 26 channels?). I could try using 12-channels as the output format to see if I get better results, but that wouldn't be a good long term solution as I actually need a 2.1 mixing target (it's a stereo pair of bi-amped speakers with a sub), so if I set the output format to a higher number of channels I'd have to do all my downmixing manually in PEQ as there's no "2.1 in a 12 channel container" type option.
I'll test that out later and see what I get, and let me know if you see anything else in the logs. Thanks for helping with this!
mwillems:
So the 12 channel thing was a red herring (it didn't make any difference), but I think I found a working config! In trying different devices the plughw: device now works, but no other hardware direct device works correctly (hw: front: and surround: prefixes either fail or make the terrible static). Part of what threw me is that the plughw: device errors outs at any sample rate other than 48k, so I initially thought it wasn't working either, but resampling to 48k works perfectly fine. That tells me that pulseaudio has the interface locked to 48k, which is almost certainly part of the problem, so I'll see if I can blacklist the UR824 in pulse and see what happens then.
But for now, plughw works exactly as expected with resampling, which is about a 95% solution. So I'm a happy camper. I'll report back if I figure out anything else.
Thanks for the help!
bob:
Great! Nice work :)
mwillems:
So final report on this for anyone with the same hardware who might land here looking for a fix. For (more or less) hardware direct audio output with JRiver and a Steinberg UR824, follow these steps:
1) Put the device in class compliant (CC) mode per the manual. It will work in non-class compliant mode, but is hardwired to 26 channels and has periodic dropouts that I couldn't resolve. CC mode shows up as an eight channel output and has no issues with dropouts. I'm not sure CC mode supports full duplex operation, but I'm using it as a DAC, not a DAW so that's fine by me. Nota Bene: If you previously used the device on Windows, you might find that the channel mapping is different on Linux. I had to swap SR and the Sub channel and SL and the Center channel to get the same mapping of outputs to channels as I had on Windows.
2) Open up pavucontrol, switch to the configuration tab, and then turn the UR824 to "off". This will cause pulse to "release" the UR824 so that JRiver can talk to it directly and automatically set the sample rate for the device. This setting persists through restarts for me when set in pavucontrol, but there's probably a way to set the interface to "off" in the pulse config files too if pavucontrol doesn't work for you.
3) Set the JRiver output device to the plughw device (e.g. "plughw:UR824"). Also make sure that the device settings PCM output format is set to "Auto." Specifying the wrong format or hardware device can lead to horrible maximum volume crunching noises (the volume seems to bypass JRiver's internal volume setting, but not the hardware volume knob on the device, so manually turn it down if you're testing things!). One thing I discovered is that S24_3LE is definitely not the "right" format as using that output format leads to crunching noises, but S24_3LE is also what the device reports it can accept, so that explains why things weren't working. When the plughw device and the "auto" PCM output format are used, the audio path shows a 32 bit output, but ALSA is almost certainly dithering down in the background as the UR824 is only a 24-bit device.
In any case, with these settings everything sounds perfect, there are no dropouts, and the device will change to supported sample rates to match source material. The only remaining issues are two minor ones. First, sometimes on sample rate changes the device "loses" the first second or two of playback, but this isn't repeatable, and isn't a big issue anyway. Slightly weirder is that when starting live TV playback (and only on TV playback) the first second or so of audio plays at maximum volume (regardless of the internal volume settings in JRiver), and then the volume goes down to whatever the actual internal volume setting is for the rest of the playback. I just turned down the hardware volume control on the UR824 to compensate. Neither of these are major issues, but if I figure out a solution, I'll post back.
Thanks again to Jim and Bob for the help on troubleshooting this.
dpe45:
Hi mwillems
I'm looking to pick up a UR824 for use on Linux so your experience is especially interesting to me.
One thing I've been unable to confirm is if all 24 channels are available when using the interface in USB Class Compliant mode.
I note you said it only shows up as 8 channels in CC mode, but maybe that is because you have nothing hooked up to the ADAT I/O.
Is there anyway you are able to confirm if 16 or 24 channels works in CC mode on Linux?
Thanks in advance
Dan
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version