Ultralite AVB

[xthechar]

[....] my other audio interface (babyface pro) [...].

How do you like the Motu device (828es you said?) vs the Babyface Ppro? I'm trying to decide between the two. TBH, I'm kinda leaning toward the Babyface Pro FS. If the Ultralite AVB or 624 AVB drivers were stable I'd go with them. But having the routing/volume controls on the device itself seems nice to avoid any driver issues, and having stable Linux support kinda overrides any other preferences.

Otherwise, awesome work! And happy New Year!

[bluebell]

Ihave the older UltraLite AVB and it runs stable with Dumfix's ua101.c driver on my notebook computer with a core i7 CPU.

Since the mixer is accessible via ethernet/Web-Browser (plus JSON/HTTP plus OSC) there is no need to handle the internal mixer/routing in an ALSA driver.

[shellwalker]

Still going fine today, about 100 hours of runtime with no channel drift. As mentioned, this is with an 828es, I don't have any other devices handy. Latest firmware.

Here's a patchset, apply on top of linux-next. Otherwise no device/ALSA-specific patches necessary here, linux-next has the relevant implicit fb improvements.
...

Curious to hear how this works for folks.

-w

Hi, I'm brand new here, but happy to have stumbled upon this community.
I got a MOTU 828ES just a few days ago and am experiencing the channel drifting issue as well.

I'd be pleased to offer help if possible. Maybe I could do some testing on my device and provide feedback?
My system is Kubuntu 20.04. I've got kernels 5.4.0-58 as well as 5.8.18 installed from Ubuntu kernel mainline.

If need be I could find my way around patching/building a kernel (just tell me what to do...).

[wrl]

[....] my other audio interface (babyface pro) [...].

How do you like the Motu device (828es you said?) vs the Babyface Ppro? I'm trying to decide between the two. TBH, I'm kinda leaning toward the Babyface Pro FS. If the Ultralite AVB or 624 AVB drivers were stable I'd go with them. But having the routing/volume controls on the device itself seems nice to avoid any driver issues, and having stable Linux support kinda overrides any other preferences.

Otherwise, awesome work! And happy New Year!

This is kind of a tough one.

RME interfaces are fantastic and in general the Babyface Pro has been good to me. The firmware and USB have been rock solid and I've never had an issue. However, I must say that the physical build is a little below what I've hoped for. The first issue is that the volume encoder on the front panel has a tendency to "jump" 6dB or so when I'm adjusting it, and then I have to keep my hand on it so I can quickly catch it and turn it down if the jump was upward (lest I damage my ears or whatever). Secondly, the USB jack on the Babyface has come loose, and depending on the orientation of the cable, the power will cut out. When I contacted RME about these issues, they said the unit was out of warranty and it would cost €250 for the repairs.

Ultimately, the Babyface does what I need it to for an on-the-go interface, but I wanted to set myself up with a studio interface to replace my old PCI HDSP+Multiface2. The hardware issues left a bad impression, and, even though I've been made aware that the pro line (such as the Firefaces that I was looking at) are of considerably higher quality construction, between the frustration with the Babyface and the fact that the UFX+ (which is the only RME that has Thunderbolt) is more than twice as expensive as the MOTUs, I went with the 828es. Also, I prefer AVB over MADI for future expansion.

I'm at some point going to take the Babyface apart and try to re-solder the USB port myself, but if that doesn't work, I may also pick up a MOTU 624 or Ultralite for mobile recording (in the event that I go more than a few hundred metres from my front door sometime this year).

Sure, there's the issue of the MOTU not... well, working, but RME doesn't fully support Linux either, and in this case it was Linux incompletely implementing the UAC spec.

-w

[wrl]

No i'm absolutely tired.

i think in xhci_urb_enqueue

Code: Select all

int lock_acquired = spin_trylock_irqsave(&xhci_lock, flags);

...

Code: Select all

if (lock_aquired)
   spin_unlock_irqrestore(&xhci_lock, flags);

should do the trick. No extra USB_HOST_LOCK_IS_ACQUIRED flag needed.

This seems dodgy to me. If the lock needs to be acquired, then being able to proceed in enqueue without it held seems like a major problem.

[wrl]

Also – tried out jack_bufsize with the URB fast completion patch. Shrinking the buffer (e.g. 1024 -> 128) results in a brief dropout (about ~1sec) while the device reconfigures, but then it comes back online without any channel drift issues. Enlarging the buffer (128 -> 1024 or whatever) happens on the fly with no dropout.

-w

[shellwalker]

Also – tried out jack_bufsize with the URB fast completion patch. Shrinking the buffer (e.g. 1024 -> 128) results in a brief dropout (about ~1sec) while the device reconfigures, but then it comes back online without any channel drift issues. Enlarging the buffer (128 -> 1024 or whatever) happens on the fly with no dropout.

-w

That really sounds great! Also kudos for the great analysis!

I'd like to give this a try on my 828ES. I tried your patch on kernel V5.11. Though the result was waaaaay more stable than ever before, it still drifted away after a few minutes.
I noticed you're doing your own tests on linux-next, so I'll shift to that as well.
1. Is there any particular tag I could use as reference?
2. Could you please provide the final version of your patch (the results of the optimizations you discussed with Drumfix)?
3. Are you submitting the patch for integration into upstream kernel?

[wrl]

Also – tried out jack_bufsize with the URB fast completion patch. Shrinking the buffer (e.g. 1024 -> 128) results in a brief dropout (about ~1sec) while the device reconfigures, but then it comes back online without any channel drift issues. Enlarging the buffer (128 -> 1024 or whatever) happens on the fly with no dropout.

-w

That really sounds great! Also kudos for the great analysis!

I'd like to give this a try on my 828ES. I tried your patch on kernel V5.11. Though the result was waaaaay more stable than ever before, it still drifted away after a few minutes.
I noticed you're doing your own tests on linux-next, so I'll shift to that as well.
1. Is there any particular tag I could use as reference?
2. Could you please provide the final version of your patch (the results of the optimizations you discussed with Drumfix)?
3. Are you submitting the patch for integration into upstream kernel?

Interesting, could you let me know what the rest of your hardware is? So far I've been testing this on an XHCI (USB 3) system but I'll build it for my laptop which is USB 2 as well, see if there's a difference on EHCI. But, things like CPU, chipset, USB host controller vendor – that would be useful.

Also, how many minutes is "a few"? How does that compare to the behaviour you've seen before?

I've been using the tag next-20201223 and applying this on top.

No optimisations yet, currently figuring out whether that's even necessary. Upstream may dictate that.

Patchset will be submitted upstream if it resolves the issues. Want to get feedback from more folks before I go through those steps, rewrite the commit messages a bit, polish it up. If I'm the only one who sees an improvement/fix from it, then... probably won't make it upstream.

-w

[shellwalker]

ok. So here's my current status:

1. I switched to linux-next (tag=next-20201223)

2. I first did not apply any patch, just to see the base behaviour -> drifting occurs as expected.
("Drifting occurs" _also_ means that the heard audio becomes somewhat distorted as time goes. Regarding how long the previous V5.11 build stayed stable, I'd need to make exact measurements if required. Do you need that?
However just in case this is relevant: the version I used is actually v5.11-rc2, not V5.11 (sorry, I should not have abbreviated that in the first place).

3. I then applied the patch file (from viewtopic.php?p=127428#p127428) without further modifications. That really looks stable to me. Meaning no drifting within the short period of time that I was actually looking at/hearing the output (something like 5 Minutes or so).

It got me thinking whether there is any test rig of some sort that would allow us to detect a fail automatically. Example: sending a known test signal out, routing that in the 828ES mixer back to linux and measuring the signal there just to see whether there is any deviation. That way we could do some long-term tests without having to manually monitor stuff.

As to your question about the details of my HW setup: Just tell me which commands (and respective options) you'd like me to gather output from (lsusb? lspci? anything else?)

[wrl]

ok. So here's my current status:

1. I switched to linux-next (tag=next-20201223)

2. I first did not apply any patch, just to see the base behaviour -> drifting occurs as expected.
("Drifting occurs" _also_ means that the heard audio becomes somewhat distorted as time goes. Regarding how long the previous V5.11 build stayed stable, I'd need to make exact measurements if required. Do you need that?
However just in case this is relevant: the version I used is actually v5.11-rc2, not V5.11 (sorry, I should not have abbreviated that in the first place).

Troubling that you're seeing this behaviour in 5.11 but not in linux-next. I'm going to investigate this.

3. I then applied the patch file (from viewtopic.php?p=127428#p127428) without further modifications. That really looks stable to me. Meaning no drifting within the short period of time that I was actually looking at/hearing the output (something like 5 Minutes or so).

That's fantastic! Okay, good data point. Would you mind leaving that running overnight or if possible for longer? I just leave a song playing on the headphone outputs so it's easy to tell from a glance at the screen if the channels are still mapped correctly.

It got me thinking whether there is any test rig of some sort that would allow us to detect a fail automatically. Example: sending a known test signal out, routing that in the 828ES mixer back to linux and measuring the signal there just to see whether there is any deviation. That way we could do some long-term tests without having to manually monitor stuff.

As to your question about the details of my HW setup: Just tell me which commands (and respective options) you'd like me to gather output from (lsusb? lspci? anything else?)

An automated test rig is something I've been really non-committal toward just because it's extra effort and I'm lazy. However, I think it definitely is the right thing to do, so as this evolves I'm going to do some loopback tests and see what's up.

I'm concerned about the 5.11 thing. I'll try the patch on rc3 tomorrow. For now, if the patch applied to linux-next is stable then I think let's just watch and see. If you end up with problems, yeah, please post your lspci and lsusb (doesn't have to be the verbose options).

-w

[tvaz]

Thanks @wrl for all your work on this.

I'd be happy to give some feedback on my Ultralite AVB with new ESS chip. I applied your patch to 5.11rc1 and everything was fine with the building. My problem now is unrelated to the audio stack, but I'll ask for help here anyway: the 5.11 doesn't boot on my encrypted file system. I played with all dm-crypt possible options, rebuilt it many times and still it doesn't recognize my ext4 encrypted fs. Any kernel < 5.11 works fine :\ Any hint would be appreciated, I'm really willing to help debugging your driver as soon as I fix this.

[wrl]

Thanks @wrl for all your work on this.

I'd be happy to give some feedback on my Ultralite AVB with new ESS chip. I applied your patch to 5.11rc1 and everything was fine with the building. My problem now is unrelated to the audio stack, but I'll ask for help here anyway: the 5.11 doesn't boot on my encrypted file system. I played with all dm-crypt possible options, rebuilt it many times and still it doesn't recognize my ext4 encrypted fs. Any kernel < 5.11 works fine :\ Any hint would be appreciated, I'm really willing to help debugging your driver as soon as I fix this.

Bit outside my experience on this one! I'd recommend checking with your distro documentation and see if there's maybe an initramfs issue.

-w

[shellwalker]

Thanks @wrl for all your work on this.

I'd be happy to give some feedback on my Ultralite AVB with new ESS chip. I applied your patch to 5.11rc1 and everything was fine with the building. My problem now is unrelated to the audio stack, but I'll ask for help here anyway: the 5.11 doesn't boot on my encrypted file system. I played with all dm-crypt possible options, rebuilt it many times and still it doesn't recognize my ext4 encrypted fs. Any kernel < 5.11 works fine :\ Any hint would be appreciated, I'm really willing to help debugging your driver as soon as I fix this.

If you're using Ubuntu, then I think just doing "make install" at the top of the linux kernel source tree should do the trick, since that takes care of calling "/sbin/installkernel".
As it appears that in turn will take care of generating initramfs and bootloader entry etc. At least that's the way that works for me.

[shellwalker]

Troubling that you're seeing this behaviour in 5.11 but not in linux-next. I'm going to investigate this.

Let me be even more precise (just in case I mixed up something):

Code: Select all

$ git show
commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62 (HEAD -> master, tag: v5.11-rc2, origin/master, origin/HEAD)
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jan 3 15:55:30 2021 -0800

    Linux 5.11-rc2

diff --git a/Makefile b/Makefile
index 3d328b7ab200..8b2c3f88ee5e 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
 VERSION = 5
 PATCHLEVEL = 11
 SUBLEVEL = 0
-EXTRAVERSION = -rc1
+EXTRAVERSION = -rc2
 NAME = Kleptomaniac Octopus
 
 # *DOCUMENTATION*

That's fantastic! Okay, good data point. Would you mind leaving that running overnight or if possible for longer? I just leave a song playing on the headphone outputs so it's easy to tell from a glance at the screen if the channels are still mapped correctly.

...

An automated test rig is something I've been really non-committal toward just because it's extra effort and I'm lazy. However, I think it definitely is the right thing to do, so as this evolves I'm going to do some loopback tests and see what's up.

Running overnight was what brought me to the question of an automated test rig. My thought was, if I came back in the morning and saw on the screen that the correct channels were being use, how would I know for sure that the drifting did not occur in the night but by chance drifted all the way back to the correct channels? [You know the issue about sampling a sine wave at exactly the frequency of the sine wave - you get a "no sine wave" observation result ]
I was thinking of using this opportunity to expand my experience with python and try to create a simple loopback test myself, so if you're too busy right now to do it yourself, maybe this could be my contribution? No promises though since I can't quite foresee how much bandwidth I have for this in the next days/weeks... But I'm motivated...

[wrl]

Running overnight was what brought me to the question of an automated test rig. My thought was, if I came back in the morning and saw on the screen that the correct channels were being use, how would I know for sure that the drifting did not occur in the night but by chance drifted all the way back to the correct channels? [You know the issue about sampling a sine wave at exactly the frequency of the sine wave - you get a "no sine wave" observation result ]
I was thinking of using this opportunity to expand my experience with python and try to create a simple loopback test myself, so if you're too busy right now to do it yourself, maybe this could be my contribution? No promises though since I can't quite foresee how much bandwidth I have for this in the next days/weeks... But I'm motivated...

Yeah, I've also considered this and acknowledge that it's a possibility, but I think in practice it's unlikely to happen. I've been using my 828es during testing for hours-long production sessions without issue, then just left it running for days after that, checking in several times a day to make sure everything was kosher.

The approaches I've tried which were unsuccessful tended to very obviously drift after 18-24 hours and then "stayed" drifted or just gradually drifted even further forward. Sure, selection bias (and your sample rate analogy is apt) but I think that the scenario where a device is drifting but only enough to consistently appear like nothing is wrong... I mean, Schrödinger's USB device, no?

Regardless – I've got a patched 5.11rc2 kernel smoke testing right now. ~24 hours in, no drifting yet.

-w