The patches can only prevent the channel flipping due to the alsa xrun recovery, not if the interrupt handling is delayed by other means.
For the device to work properly with USB following RT priorities is necessary:

Highest priority: the IRQ thread of the USB ehci host controller
Second highest: the ksoftirqd process that runs on the same perocessor core as the IRQ thread
Third highest: The audio process of the application

This works best if all three components are pinned to the same processor core and all other IRQs removed from the core.
Note, that renoise uses an exceptionally high RT priority (95) for its realtime threads, so i recommend to set a RT priority of 98 for the USB IRQ and 97 for the ksoftirqd

As for the state of AVB driver.
Currently it only provides 1 input stream and 1 output stream with 8 channels each that autoconnect to the Motu with hardcoded samplerate, stream id and destination MAC address. So not intended yet for the casual user. Operation though so far is flawless.

Achievable roundtrip latencies can be calculated by following formulas (verified using the Windows tool "RTL Utility" running with Wine/Wineasio):

Drumfix, thanks for the advice about thread priority! I've made my audio output apparently stable by just reducing the realtime priority of the host thread. I think the priority of those other threads was set properly (thankfully, as I'm not sure how to change it), and I just needed to decrease the priority value at the application level.

For some reason, though, audio is still playing out of the wrong channel. The routing is wrong, but seems to be static; that is, audio sent to channel 1 will always come out channel 17. I can deal with this, of course, by just using a routing matrix that inverts this odd behavior, but it might be worth noting at least. Any idea why this could happen? Oddly, the inputs seem mapped fine, but the outputs have this issue.

After trying it again last night, the channel jumping has returned. I thought it was an issue of the priority value on my DAW being set too high, since lowering it appeared to fix the issue earlier. Not sure what changed since then.

I'm afraid I'm a little new to this; how do I query or modify the priority values for the two other threads mentioned by Drumfix? How do I pin them to the same processor?

Unfortunately, it's still not working. I've compiled my realtime kernel with the patches (formerly it wasn't a realtime kernel, but I've figured that out!) I've opened my MOTU interface with 3 periods, and a realtime priority of 0 or 40, and your script doesn't seem to fix the channel hopping. I've attached the full output of your script on my machine, but the most alarming part is "line 29: /proc/irq//smp_affinity: No such file or directory"

Again, I really appreciate your help on this matter. Any idea what could be going on with my system?

You do not have the required permissions to view the files attached to this post.

Stanlea, the channel hopping seems to be the only issue. Audio plays cleanly through some channel for some time (sometimes seconds, sometimes minutes), and then hops over to a different one. Sometimes that hopping takes a few seconds, during which audio fades crunchily on the channel it's leaving, but I think that the channel hopping is the only thing wrong. It's always the same channels too. 1 and 2 jump over to 17 and 18, then 11 and 12 (I think).

I'm a bit stuck; I thought switching to the patched realtime kernel and running that script to enforce proper thread priorities would fix this.

pemberley wrote:Stanlea, the channel hopping seems to be the only issue. Audio plays cleanly through some channel for some time (sometimes seconds, sometimes minutes), and then hops over to a different one. Sometimes that hopping takes a few seconds, during which audio fades crunchily on the channel it's leaving, but I think that the channel hopping is the only thing wrong. It's always the same channels too. 1 and 2 jump over to 17 and 18, then 11 and 12 (I think).

I'm a bit stuck; I thought switching to the patched realtime kernel and running that script to enforce proper thread priorities would fix this.

Thanks pemberley, I was asking because there are a lot of topics in one, and this thread is more now about the MOTU AVB range than just the Ultralite AVB. On my side (and this explains a little more my questions) I have just bought a 828ES, and was crossing fingers about the stutter bug. And I had it.
But flashing the bios of the unit with the very first version the firmware solved it. At least until now, I need to make some more tests in order to be sure about the performance of the card. Actually I have no channel hopping. Are you using Jack 1 or Jack 2 and what are your settings (channels numbers, frames,...)

Well after a week or so playing around with v1.2.9+1280 it isn't stable for me, even with no USB plugged in! I keep getting UI lock-ups, both the web and the unit itself although the audio continues to work fine...... back on the latest update now which 'was' fine.

edit: so this was a complete lie..... this was a network issue, more specifically a VLAN tagging issue. Back on v1.2.9+1280 now and all is stable. So the network interface is just as sensitive as the USB interface

Big hands up for testing the AVB ethernet driver whenever its ready

Last edited by jmccoy555 on Sun Feb 17, 2019 6:42 pm, edited 1 time in total.

That's dealt with the error in the script, but unfortunately audio is still bouncing around between channels. I've attached the updated output of your motu.txt script. I've set the sample rate to 96k, 24 bits, priority value of 60 selected in Reaper. I've tried buffer sizes of 256 and 1024 samples, and periods of 2 and 3. It doesn't seem to care whether I use JACK or not; usually I've been testing right on top of ALSA. Also, I tried using one of the USB 2 only ports on my computer, just in case that happened to change anything.

Any ideas? Again, thanks for all your help so far.

You do not have the required permissions to view the files attached to this post.