LinuxMusicians

Earlier this week I did some minor kernel hacking, including backporting the aforementioned patch by Adam Goode to my current kernel (Ubuntu's 4.15.0-29-generic*) and creating quirk entries to get rid of the "clock source 1 is not valid" messages. None fixed the bitcrushing issue.

It's a shame really. The big draw of the UltraLite for me was that, having DC-coupled outputs, it can send control voltages to my modular synth without any extra hardware, a feature that I greatly enjoyed in the few hours of solid operating time I got out of the MOTU.

* It's around half a year out of date compared to tiwai's sound branch on GitHub, but I eyed through the commit log for that time period and at least couldn't spot anything that could potentially fix the issue. Goode's patch explicitly mentioned an external clock source though, which I'm not using.

Just ordered one of these as an upgrade from my Scarlett 2i4 that I couldn't get working, only to come across this. I'm praying that alsa patch fixes this problem for me.

How can I tell when that patch gets merged into the kernel?

rofer wrote:How can I tell when that patch gets merged into the kernel?

I'm not familliar with how Linux kernel releases are managed, but the patch in question: https://github.com/tiwai/sound/commit/5 ... d7a438b11b is currently in Takashi Iwai's "for-next" branch, which I assume will get merged into the next major kernel release after 4.18 (presumably 4.19).

I wouldn't really count on it fixing this issue, though. If you have no particular reason for choosing this exact interface, it would probably be a good idea to return it and buy an RME like everyone is suggesting.

I buy all of this stuff used so I don't think there's an easy way to return it, plus if this issue is fixed it seems like it should be the perfect interface. Class compliant with a web control over all of the internal effects / mixing / etc. While I don't strictly need the DC-coupled outputs with the Expert Sleepers modules I have, I do view them as a plus too.

That all seems like a step above what RME does, plus RME stuff also costs an extra $100 on eBay. I'm hopeful that patch is a sign that someone who knows what they're doing is trying to fix things and so if they're not fixed yet, they should be soon enough. Hopefully I'm not being too optimistic.

Also, thanks for the link to Takashi Iwai's repo.

Just got mine and it seems like I'm having things worse than most people. The crushing happens for me within 30s (often less) and my audio spends more time dropped out than not.

Edit: I can't seem to even get LTC to fix things. It keeps getting out-of-sync, especially when I'm using pulse audio bridged through jack.

rofer wrote:Just got mine and it seems like I'm having things worse than most people.

Try downgrading your FW.

Since especially the last FW introduces more bit-crushing, the key for our problem lies there.

The sad thing is, someone capable at MOTU could fix this or at least give us a hint in the right direction in minutes

I’ve tried reaching out to MOTU numerous times about the issue and they did try helping me in the beginning but once they realized I was on Linux they said they couldn’t help me any further. Best bet is older firmware which I still have somewhere on a backup drive but you don’t get the touch console which is really nice to have live. If not I’d really consider RME if you’re able. It doesn’t have AVB but it’s rock solid even on Linux in class compliant mode. MADI for me is enough considering how great the drivers are for these units on a Mac and the quality of the units themselves.

Two things.

First, I emailed Matt Goode about the patch he wrote and here was his response:

This fix to the kernel addresses the main kernel bug that I saw, which makes it hard to change the rate. It mostly happens when the clock is external, but it can happen any time. There are at least two other classes of problem that user programs (pulseaudio, jack, etc) need to handle:

1. The clock takes a long time to stabilize, especially after clock changes. ALSA checks this and rejects the open if the clock is not valid. Userspace programs should retry opening the audio device. Alternatively, ALSA could be changed to allow opening the device even if the clock is not valid. This is probably a good idea, since nothing stops the clock from becoming invalid while the device is open, so things can always go wrong. Non-USB devices don't have this ALSA behavior, it is specific to the USB code in ALSA.

2. Programs don't handle rate changes correctly. See https://gitlab.freedesktop.org/pulseaud ... issues/532.

Second, I just noticed something that seems significant about the bitcrushing stuff I'm experiencing on the latest firmware. It happens well within a minute of trying to play something back and when I look at the routing matrix I can see a bit of what's going wrong. Rather than just playing back on channels 1 & 2 (which is my goal), I instead see the sound jump around going to either 9 & 10 or 17 & 18. If I keep re-routing it I can get my audio back. Occasionally the audio gets split across two different pairs of channels which is when the bitcrushing happens.

It looks to me like either the kernel or the interface is mixing up which streams are which. The fact that everything is right mod 8 (1 % 8 = 9 % 8 = 17 % 8) hopefully will help debug what's happening.

From my limited testing so far using the interface as a router works even when I'm getting the bitcrushing elsewhere. I connected a synth and I could still direct it to my headphones even while I watched the audio my computer was trying to play bounce around across the inputs.

My hope is with this information someone will be able to find what's wrong and fix it. I haven't written any kernel code before, but if no one else steps up I'll certainly give it a try.

Edit: Similar things happen with other channels too. Trying to send an LTC signal to channel 21 doesn't work because it bounces between 21, 13, and 5 which are also all the same modulo 8.

I've done some more debugging and determined this happens going both directions. Audio coming out from the computer can get mis-aligned and audio going into the computer can also get mis-aligned.

To figure out if recording was also getting messed up I recorded a synthesizer playing into my laptop (on channel 7) while I played a stereo audio track out (on channels 1&2). My setup and the results can be seen here:


The thing to notice is that while at first the synth track and the audio track move together, later the audio track moves without the synth. This is showing that things can get mis-aligned going in both directions.

Do you have pulseaudio running?

Maybe it is shuffling around the channels in the background in packets of 8 channels, treating the device as several 8 channel interfaces.

None of this was running directly through pulseaudio.

I mostly connected to the interface through jack, then bridged pulseaudio to send things to it.

However, I confirmed this still happens if I use aplay to send audio to the interface directly, so I'm pretty sure the problem is in alsa (or the inerface) and not jack or pulseaudio.

Is what you experience the same as this ?
https://www.spinics.net/lists/linux-aud ... 07693.html

If that's the case i would recommend to prevent the driver from changing the sample rate and pitch, i.e

sound/usb/clock.c: sound/usb/pcm.c: and then in the application just select the samplerate that is already set by the web interface and unplug/replug the interface.

Drumfix wrote:If that's the case i would recommend to prevent the driver from changing the sample rate and pitch

I've tried this to no avail. The same glitch occurs even after disabling sample rate and pitch changing.

I've only been using the Ultralite as a mixer (coupled with an 8A over optical). I didn't notice these serious problems with the interface, but was easily able to reproduce by playing some audio for a little while. Originally I thought there were problems with jack, but I was able to reproduce with regular ALSA.

Does anyone know how to trigger the issue consistently? I noticed it just happens after a while but would like to try to figure out a way to cause the failure more quickly.

I was afraid that was going to be the case since I get this problem using alsa directly through aplay which I don't believe does the stream reconfiguration supposedly implicated in the channel remapping.