bluebell wrote: ↑Thu Sep 03, 2020 3:24 pm
I got the source from kernel.org and all I did was replacing sound/usb/misc/ua101.c completely.
I didn't apply any patches.
Well I figured out the patch system and now I'm on a patched 5.8.6 and all seems well so far (about 30 mins) so congrats and thank you to you and drumfix for a working patch!
Some gotchas in my case (MOTU 1248):
Asmedia 3.1 port didn't work, Intel 3.0 port does
Must boot with it connected and turned on
Set midi property in motuavb.conf to false
Set number of I/O channels in Routing page to 8x8
This is just a plain Manjaro KDE install other than patch, haven't tried JACK yet
I really just installed Manjaro in the hopes that 5.8 would work OTB and have ended up here. So next up for me is to install JACK, etc. and see how that all goes. I might even just re-install Ubuntu Studio and try patching that instead.
You can force loading of the driver on boot by putting a line into the file /etc/modules (including the module parameters).
See "man modules".
You can check what driver the device is using by "lsusb -t"
Important is to look at inderfaces 0,1,2.
If they are using snd-usb-audio then just execute the following commands:
No samplerate changes !! It went from "kinda working" to "just working". I want to thank Drumfix and Bluebell for their work and help. The 828 is now a killer soundcard for my use.
mxxxl wrote: ↑Fri Sep 11, 2020 10:11 am
Hi,
I have been using the driver for about a week now in a production environment with kernel 5.8.5, it works flawlessly!
Thank you!!
What interface exactly? UltraLite AVB? The old one or the new one with ESS chips?
i have the same issues as root2 with the new driver. I have also the Ultralite AVB ESS with Firmware 1.3.5+637. In the moment i'm testing with kernel 5.8.8.
If I use the device only with Pulseaudio, i have sometimes distortions and sound disappears. If using with jackd sound disappears immediately
sometimes after 10-20 minutes, sometimes after hours of use. Restarting jackd helps.
root2 wrote: ↑Sun Sep 13, 2020 4:53 pm
I got channelhopping and distortion after some days with the new driver as well I have the Ultralite AVB ESS Version with latest firmware.
lsusb -t | ag motu
|__ Port 4: Dev 4, If 3, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 1, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 4, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 2, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 0, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 5, Class=Vendor Specific Class, Driver=snd-motu-avb, 480M
lsusb -t | ag motu
|__ Port 4: Dev 4, If 3, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 1, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 4, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 2, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 0, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 4: Dev 4, If 5, Class=Vendor Specific Class, Driver=snd-motu-avb, 480M
Hi all, I've been following this thread for a long time...
I am starting to test the ua101.c driver (thanks for the work on this!!, kudos to drumfix!) on an 8M with firmware 1.3.5+1434. This is running under Fedora 32 / 5.8.9 with "threadirqs" enabled and setting the rt priority of the audio interface irq handler properly for best Jack performance. The driver loads and seems to work. I am testing it by running Jack at 128 frames per period (2 periods, 48KHz).
I had a couple of instances of sound dropping out completely after a few minutes in my first test. I was connecting a microphone to headphones through Jack - this was not channel hopping as connecting the single mic input to all outputs did not indicate signal, and nothing was seen (no output) in the audio interface web interface. I was not listening in so I don't know how it happened. Stopping Jack and restarting it twice seemed to fix the problem. Nothing relevant in the output of dmesg.
I have moved the card to a different USB port (the one I was using before), just in case.
...
No change. I just saw this happen again after about 1/2 hour of running fine. No sound output (which might mean no sound I/O at all). Restarting Jack returned sound to normal. I have to do more tests the next time this happens (test through pulseaudio before restarting Jack, etc).
I see occasional xruns which is not encouraging (in terms of low latency performance). Maybe I will have to try this driver with an RT patched kernel and the new ua101.c driver (would have to be 5.9.rc or 5.6).
Question: would it be possible to use this driver with the vendor endpoints instead of the standard endpoints? I do have use cases where I need all 64 channels, so having this available would be wonderful (I had been running with the previous vendor endpoint patches)...
lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
|__ Port 6: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 2: Dev 17, If 4, Class=Vendor Specific Class, Driver=snd-motu-avb, 480M
|__ Port 2: Dev 17, If 2, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 2: Dev 17, If 0, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 2: Dev 17, If 5, Class=Vendor Specific Class, Driver=snd-motu-avb, 480M
|__ Port 2: Dev 17, If 3, Class=Vendor Specific Class, Driver=snd-motu-avb, 480M
|__ Port 2: Dev 17, If 1, Class=Audio, Driver=snd-motu-avb, 480M
|__ Port 6: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 13, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 14, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 14, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 14, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 8: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 8: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 9: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 11: Dev 7, If 0, Class=Chip/SmartCard, Driver=usbfs, 12M
|__ Port 13: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 14: Dev 9, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 14: Dev 9, If 1, Class=Wireless, Driver=btusb, 12M
More testing (5.8.9 + ua101.c driver on a Motu 8M)
Well, it is channel hopping. Sad. I can now see the output in channels 17/18 instead of 1/2. And as I type this 17/18 are suddenly silent and I can't see output on any other channels. Jack is still happy and nothing seems amiss, numbers increase in the proc ALSA status (so alsa presumably thinks it is sending and receiving?):
I am successfully running the older vendor endpoint patch on 5.8.9, using the proprietary USB endpoints (4 & 5) and running at 48KHz and 64 channels on a Motu 8M. This requires a patched kernel bzImage (in addition to patches in the sound USB kernel module) because the current USB core code detects both endpoints as duplicated and disables the second one (which is the one we need to use). And the audio interface needs to be switched to the proper mode with the right curl http magic invocations...
In a long test yesterday evening there was no channel hopping, and furthermore, I was no longer experiencing audio corruption like before - every once in a while the interface started making high frequency noises and buzzes, sometimes constantly and sometimes interlaced with segments where the sound quality was fine (at, say, about 1 second intervals). I could fix that by restarting Jack, but that obviously is not good if you are performing over the network with a group
This is no longer (apparently) happening under 5.8.9, and while there were some xruns running Jack with 128 frame buffers, the audio quality was good with no weird buzzing or glitches, maybe because - I think I read this somewhere, probably on this thread - the 5.8.* kernel now supports the proper USB synchronous mode the newer Motu firmware uses.
It would be great to somehow incorporate this mode of operation (if possible) into the ua101.c driver...