Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So this is a long shot, but I wanted to post here in case anyone might have any tips or insight on a technical issue I've been struggling with on and off for a few years.  The Steinberg UR824 is an 8-channel DAC that I've been using successfully in windows with an ASIO driver.   

However, the Steinberg also has a "class-compliant" mode that will let it function as a USB Audio Class 2 compliant device, which means it should work correctly with Linux.  When I put the UR824 in class-compliant mode and connect it to a Linux PC, pulse audio "sees" the UR824 as an 8 channel device and normal Linux audio applications will play to it through pulse with no manual configuration of any kind.  So far so good.

In JRiver, if the Steinberg is the default output, and I set the JRiver output device to "default" or to "pulse" everything works fine, I can play to all eight channels and things work perfectly.  However, if I try to output in JRiver to any of the hardware direct modes (front:, hw:, surround71:, etc.).  I get horrifying crunching distortion at maximum volume!  Needless to say I've been reluctant to try too many things when the failure mode is 100dB crunching noise, but I did try each of the hardware outputs in JRiver and they all fail the same way.  This problem has existed for a few years, and in every Linux distro I've tested.  I would really prefer to be able to address the hardware directly in JRiver for a few different reasons (e.g. I need the system default sound output to go to a different device, but want JRiver to output to the Steinberg).

So I was wondering if anyone here encountered a similar issue either with this specific hardware or other hardware?  Barring that, obviously pulseaudio is able to see and autoconfigure the device correctly, so it can work in the Linux environment; there's just some difference in the way JRiver is addressing the hardware I suspect that's causing this issue.  I suspect there might be some ALSA configuration trick that might be able to smooth this out, but I just don't know enough about the way JRiver is addressing the device to know what might be the issue. 

Bob, if you or anybody at JRiver have any thoughts, I can post logs, but I know this is a pretty niche issue so no worries if you guys have bigger fish to fry. 

[JimH]

No idea, but is a firmware update possible?

Does it work with another player?

[mwillems]

No idea, but is a firmware update possible?

Does it work with another player?

I tried updating to the latest device firmware with no change, but that's a good idea.

It works with other players, but all the other players that I use go through the pulse mixer, and JRiver works fine too when pulse is in the middle.  I don't have another player on hand that uses an ALSA direct type music connection like JRiver does.  That's a good avenue for investigation though, I'll poke around and see if maybe I can find a Linux music player that will talk directly at the ALSA layer and see if it has the same issue.

[JimH]

Can you ask Steinberg if they know of a player that works?

[bob]

Try running /usr/lib/jriver/Media\ Center\ 28/alsacap and posting the results here.

[mwillems]

Alsacap gives me this

Code: [Select]

*** Scanning for playback devices ***
Card 0, ID `m2x4HD', name `miniDSP 2x4HD'
  Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)
    2 channels, sampling rates 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
Card 1, ID `UR824', name `Steinberg UR824'
  Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)
    12..26 channels, sampling rates 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S24_3LE
      Subdevice 0, name `subdevice #0'
Card 2, ID `Mic8k', name `ZY Control Mic8k'
Card 3, ID `CODEC', name `USB Audio CODEC'
  Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)
    1..2 channels, sampling rates 32000, 44100, 48000 Hz
    Sample formats: S8, U8, S16_LE
      Subdevice 0, name `subdevice #0'
Card 4, ID `PCH', name `HDA Intel PCH'
  Device 0, ID `ALC892 Analog', name `ALC892 Analog', 1 subdevices (1 available)
    2 channels, sampling rates 44100, 48000, 96000, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 1, ID `ALC892 Digital', name `ALC892 Digital', 1 subdevices (1 available)
    2 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
Card 5, ID `NVidia', name `HDA NVidia'
  Device 3, ID `HDMI 0', name `HDMI 0', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 7, ID `HDMI 1', name `HDMI 1', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 8, ID `HDMI 2', name `HDMI 2', 1 subdevices (1 available)
    2 channels, sampling rates 32000, 44100, 48000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 9, ID `HDMI 3', name `HDMI 3', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 10, ID `HDMI 4', name `HDMI 4', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 11, ID `HDMI 5', name `HDMI 5', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 12, ID `HDMI 6', name `HDMI 6', 1 subdevices (1 available)
    2..8 channels, sampling rates 32000, 44100, 48000, 88200, 96000, 176400, 192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'

Card #1 is the relevant one. 

Here's the relevant info from pulseaudio (pactl list sinks) in case that helps:

Code: [Select]

Sink #3
State: SUSPENDED
Name: alsa_output.usb-Yamaha_Corporation_Steinberg_UR824-01.multichannel-output
Description: Steinberg UR824 Multichannel
Driver: module-alsa-card.c
Sample Specification: s24le 26ch 44100Hz
Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe,side-left,side-right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11,aux12,aux13,aux14,aux15,aux16,aux17
Owner Module: 11
Mute: no
Volume: front-left: 16848 /  26% / -35.40 dB,   front-right: 16848 /  26% / -35.40 dB,   rear-left: 16848 /  26% / -35.40 dB,   rear-right: 16848 /  26% / -35.40 dB,   front-center: 16848 /  26% / -35.40 dB,   lfe: 16848 /  26% / -35.40 dB,   side-left: 16848 /  26% / -35.40 dB,   side-right: 16848 /  26% / -35.40 dB,   aux0: 16848 /  26% / -35.40 dB,   aux1: 16848 /  26% / -35.40 dB,   aux2: 16848 /  26% / -35.40 dB,   aux3: 16848 /  26% / -35.40 dB,   aux4: 16848 /  26% / -35.40 dB,   aux5: 16848 /  26% / -35.40 dB,   aux6: 16848 /  26% / -35.40 dB,   aux7: 16848 /  26% / -35.40 dB,   aux8: 16848 /  26% / -35.40 dB,   aux9: 16848 /  26% / -35.40 dB,   aux10: 16848 /  26% / -35.40 dB,   aux11: 16848 /  26% / -35.40 dB,   aux12: 16848 /  26% / -35.40 dB,   aux13: 16848 /  26% / -35.40 dB,   aux14: 16848 /  26% / -35.40 dB,   aux15: 16848 /  26% / -35.40 dB,   aux16: 16848 /  26% / -35.40 dB,   aux17: 16848 /  26% / -35.40 dB
        balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source: alsa_output.usb-Yamaha_Corporation_Steinberg_UR824-01.multichannel-output.monitor
Latency: 0 usec, configured 0 usec
Flags: HARDWARE DECIBEL_VOLUME LATENCY
Properties:
alsa.resolution_bits = "24"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "USB Audio"
alsa.id = "USB Audio"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "0"
alsa.card = "1"
alsa.card_name = "Steinberg UR824"
alsa.long_card_name = "Yamaha Corporation Steinberg UR824 at usb-0000:00:1d.0-1.7, high speed"
alsa.driver_name = "snd_usb_audio"
device.bus_path = "pci-0000:00:1d.0-usb-0:1.7:1.1"
sysfs.path = "/devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.7/3-1.7:1.1/sound/card1"
udev.id = "usb-Yamaha_Corporation_Steinberg_UR824-01"
device.bus = "usb"
device.vendor.id = "0499"
device.vendor.name = "Yamaha Corp."
device.product.id = "1505"
device.product.name = "Steinberg UR824"
device.serial = "Yamaha_Corporation_Steinberg_UR824"
device.string = "hw:1"
device.buffering.buffer_size = "1048554"
device.buffering.fragment_size = "524238"
device.access_mode = "mmap+timer"
device.profile.name = "multichannel-output"
device.profile.description = "Multichannel"
device.description = "Steinberg UR824 Multichannel"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-usb"
Formats:
pcm

One interesting thing I noted is that pulse and alsacap seem to be seeing a different supported PCM output format (S24_LE vs. S24_3LE)?  Not sure how significant that is.  When I try to set MC to use S24_LE like pulse seems to do, playback just fails (no loud noise).

[bob]

That's interesting.
Especially because it says it ONLY supports S24_3LE.
So it appears to also be letting it be opened under another format?
If you leave MC on Auto and look in the log you should be able to see what format it's actually using.
Would you post that here please?

[bob]

That's interesting.
Especially because it says it ONLY supports S24_3LE.
So it's appears to also be letting it be opened under another format.
If you leave MC on Auto and look in the log you should be able to see what format it's actually using.
Would you post that here please?

My guess is that it is using S24_3LE, supposedly S24_LE isn't supported over USB.

[mwillems]

That's interesting.
Especially because it says it ONLY supports S24_3LE.
So it appears to also be letting it be opened under another format?
If you leave MC on Auto and look in the log you should be able to see what format it's actually using.
Would you post that here please?

Sure, I'll try and do that this evening when I'm back in front of the interface.

[bob]

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?

[mwillems]

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?

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

[mwillems]

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

The Alsa output and pulse seem to "see" it as an eight channel output and multi-channel input device in class-compliant mode.  I don't have any ADAT inputs or outputs, so I have no way to test whether all channels are actually addressable in class compliant mode, unfortunately, but I'd doubt they'd appear if I plugged something in, because the extra inputs show up immediately in non-class compliant mode with nothing attached (and I've never seen another Linux device that advertises it's capabilities that way).

FWIW, I'm fairly sure the extra outputs are actually addressable in non-class compliant mode, as the device shows up with 26 outputs and I found a few posts online from folks that suggest they've gotten it working that way for DAW use.  I didn't get good results from the non-class compliant mode, obviously, but that doesn't mean it's impossible.  I think getting good performance in non-class compliant mode might require some device configuration in windows first, that the device will "remember" after the switch to Linux, but I'd already been using the device with windows for years so already had my preferred configuration. 

I'll be honest, if I were starting fresh, I probably wouldn't have bought a UR824 for Linux use.  I just happened to already have one that I wanted to migrate.  My understanding is that some of the slightly older Focusrite devices are a bit better for Linux use?