LinuxMusicians

shellwalker wrote: ↑Thu Apr 15, 2021 5:59 pm
Thanks a lot Drumfix! That certainly throws another light on the whole discussion....
It seems that all the fuss about fixing Linux may have been wasted effort.

OK. I took on the challenge and tested my MOTU 828ES on my old Macbook Pro with multi-boot setup.
I connected the MOTU via USB (not Thunderbolt, since my Mac does not have TB) and used the same port for running an Ardour test under both Linux and Mac-OS.

Here are my results:
1. Mac OS (Version 10.10.5 "Yosemite"): Ardour runs fine. Testsignal ran stable for over 2 hours until I stopped the test. No drifting and no distortion whatsoever.

2. Ubuntu (Version 18.05.5 LTS. Kernel = 4.15.0-142): Drifting and distortion occurs pretty soon after start or even immediately. Sometimes the test starts without any sound to be heard.

Conclusion:
To me it appears that the problem is actually Linux!
Any other opinions or explanations?

shellwalker wrote: ↑Fri Apr 16, 2021 6:48 pm

shellwalker wrote: ↑Thu Apr 15, 2021 5:59 pm
Thanks a lot Drumfix! That certainly throws another light on the whole discussion....
It seems that all the fuss about fixing Linux may have been wasted effort.

OK. I took on the challenge and tested my MOTU 828ES on my old Macbook Pro with multi-boot setup.
I connected the MOTU via USB (not Thunderbolt, since my Mac does not have TB) and used the same port for running an Ardour test under both Linux and Mac-OS.

Here are my results:
1. Mac OS (Version 10.10.5 "Yosemite"): Ardour runs fine. Testsignal ran stable for over 2 hours until I stopped the test. No drifting and no distortion whatsoever.

2. Ubuntu (Version 18.05.5 LTS. Kernel = 4.15.0-142): Drifting and distortion occurs pretty soon after start or even immediately. Sometimes the test starts without any sound to be heard.

Conclusion:
To me it appears that the problem is actually Linux!
Any other opinions or explanations?

1.) There is a bug in the Linux kernel that hides as long as USB communication flows as expected.
2.) The Apple implementation is not so standard as it should be and so the MOTU implementation had to be tweaked, too, which causes problems with a standard implementation in the Linux kernel.

I personally think that the first case is the most likely.

Drumfix wrote: ↑Thu Apr 15, 2021 6:41 am Btw early in this thread i posted a userspace program using libusb to copying what is received from the inputs directly to the outputs without alsa being involved at all. And it also experiencing the bug.

viewtopic.php?p=96236#p96236

@Drumfix:
I just thought about your statement a bit more... My understanding is that libusb (and as such your userspace program) still uses the kernel to access USB, right? So if there is a bug in the USB stack, then this will show up also in your program.
But at least it would rule out the ALSA layer as being the culprit and that is already a time saver and great finding!

Is it possible to use your program to create a defined signal to send to the MOTU device (something like a defined sequence of numbers; this does not need to be an audible sound signal...)? If yes, is it possible to trace that known signal down to the buffer level in the kernel (so to say just before things get written to hardware), printing out debug infos so that we can detect where things start to go wrong? (I'm still assuming the fault is in the Linux kernel).

@fohdeesha: great work and great find.


The non-ES version unfortunately doesn't have the auto-power jumper.
I guess the relevant GPIO is missing as well.

Btw, I should've disconnected the ribbon cable way before, now the knobs don't work anymore of course,
but the interface (especially the display) is finally dark now
Maybe there's a way to disable it in software as well? /opt/scmd? change something in /etc/init.d to not initialize it?

To answer my own question regarding chromium:
See https://www.motunation.com/forum/viewto ... 14&t=68285 .
I couldn't believe it, but zooming in and out while refreshing really fixed it.
I can now use the webinterface from vivaldi again.
This is so sad.


For the record, channel hopping also happens on windows:
https://www.motunation.com/forum/viewto ... 14&t=67753

Really nice to see major traction regarding our "beloved" Ultralites

Will all new information about the device in any way help us get network access to the device over usb ?
using localhost:1280

it is not that important compared to the audio glitches but would be helpful for users with more than one avb device and no avb switch.

Musinux wrote: ↑Sun Apr 18, 2021 10:50 am For the record, channel hopping also happens on windows:
https://www.motunation.com/forum/viewto ... 14&t=67753

Oh, wow, that's interesting and might mean that there's a bug in the MOTU firmware.

Digging a bit in the filesystem...

found the json file with the anoying arbitrary channel limit.

/opt/DeviceDescription/dd_UltraLite\ AVB.json

"MaxChUSB2": "64:32:24",
"MaxChUAC": "24:24:24",

I hope there is a way to inject better values and get the bang for the buck.

/Anders

64 channel mode is working just fine when the necessary kernel changes are applied and the curl command executed.
However executing the curl command must be done over the ethernet connection.
Unfortunately the USB connection uses in its commands some unknown 4 bytes, my guess it is some crc32, and the device will not accept commands with that 4 bytes not being correct.

Drumfix wrote: ↑Tue Apr 20, 2021 10:12 pm 64 channel mode is working just fine when the necessary kernel changes are applied and the curl command executed.
However executing the curl command must be done over the ethernet connection.
Unfortunately the USB connection uses in its commands some unknown 4 bytes, my guess it is some crc32, and the device will not accept commands with that 4 bytes not being correct.

Ok, great to know. Thanks

Just did another look at the 4 mystery bytes. They are indeed a standard CRC32 caculated over the remainder of the message starting with UTOM.

Channel Hopping Fix!
So I just updated my Raspberry Pi 4b to Ubuntu 21.04 (Hirsute Hippo) and I stumbled upon a fix for the channel hopping with jack with my Stage-B16

Enabling "-s" for soft-mode in jackd seems to fix the channel hopping

here is an example of my command

### No channel hopping ###
jackd -R -P89 -dalsa -dhw:CARD=StageB16,DEV=0 -r48000 -p64 -n2 -s

and with the "-s" soft-mode flag removed I get channel hopping

#### Channel hopping and glitches ###
jackd -R -P89 -dalsa -dhw:CARD=StageB16,DEV=0 -r48000 -p64 -n2

also the stage-b16 didnt seem to work with jack at all until I left the stage-b16 running while connected to USB while the raspberry pi powers up and boots
I hope this helps

UPDATE: well looks like I spoke too soon. although it hops less with soft-mode, it's still not cured

Drumfix wrote: ↑Tue Apr 20, 2021 10:12 pm 64 channel mode is working just fine when the necessary kernel changes are applied and the curl command executed.
However executing the curl command must be done over the ethernet connection.

That is what I have been using and it has been quite stable. I am running kernel 5.9.1 but found that the usb driver has changed a lot in the latest kernels (and I have not yet figured out how to adapt the patch). Any chance there is a newer version of the patch for, say, 5.11?

Datapoint: I was running into problems a few days ago, I was getting periodic high frequency glitches (a known problem I have seen before). Restarting jackd would solve them, but they would reappear. I had a browser running on a different computer and accessing the mixer page for the same audio interface (8M running the latest firmware). Switching to the matrix display (instead of the mixer) made the glitches go away immediately.

So it would seem that non-AVB ethernet traffic to the motu box from a _different_ computer than the one connected through USB can influence USB transfer reliability inside the Motu...

As mentioned earlier in this thread i use my own driver based on the ua101 driver.

Modify in drivers/usb/core/config.c the function config_endpoint_is_duplicate so that it always returns false (just remove everything in this function except the "return false" statement at the end).

Blacklist the Motu AVB in the snd-usb-audio driver:

In snd/usb/card.c modify the function usb_audio_probe. Copy the attached ua101.c over the original file in sound/usb/misc.

The driver has 4 options:
samplerate (obvious)
queue_length = internal output queue length in microframes. Influences latency and therefore possibility of channel hopping
midi = must be set to 1 for all devices that have a midi port, 0 for all others
vendor = 1 for proprietary mode, 0 for class compliant mode

Currently additionally proprietary mode must be activated by the curl command. Now that i know how to communicate with the device over USB i will add the related command to the driver soon.

Drumfix wrote: ↑Mon Apr 26, 2021 6:45 am Now that i know how to communicate with the device over USB i will add the related command to the driver soon.

This sounds like there's a real chance to make it work. Another great find, thank you.


Did anybody see viewtopic.php?f=6&t=20936
Essentially leading to this kernel patch: https://git.kernel.org/pub/scm/linux/ke ... aaa94339dc
"This fixes crackling sound during playback."

The patch is from 2020.

The last post in the thread is from march 2021 and sounds like the M2 is "working".

Did those M2/M4 and microbook interfaces really only need that quirk to work?

Drumfix wrote: ↑Mon Apr 26, 2021 6:45 am As mentioned earlier in this thread i use my own driver based on the ua101 driver.
...
Currently additionally proprietary mode must be activated by the curl command. Now that i know how to communicate with the device over USB i will add the related command to the driver soon.

Thanks for the driver and the details!

Ah, I had been using the patch that adds the extra quirk (in the old quirks file). I think I tried your ua101 driver at some point (maybe last September) and it had problems, but regretfully I do not remember exactly what happened, sorry about that. I went back to the old one because it was mostly working.

I will try this one out (there are a few diffs with the last one I had downloaded) and report results (I am using one 8M and one 16A)...