Ultralite AVB

[buonamorte.records]

... This way, no channel hopping but after 60 minutes more or less the sound is corrupted and i need to restart jack or alsa to have a good sound again.

This is yet another occasion of " Look! I've solved it! It works now.....errrr...Wait, no it isn't working after all".
That just confirms my summary of the overall observations a few posts ago.

I fear that in order to really achieve a true solution, the actual root cause needs to be understood, not just assumptions made. To that end, I guess the best approach would be to analyze the USB stream on the physical bus.
That requires following things:

1. Someone with a USB analyzer.
2. Someone with USB expertise to understand the traces and identify what is going wrong in the stream.
3. Someone with kernel USB know-how to track down the responsible code location and fix it.

I have none of the above things, though I had contemplated on buying a USB analyzer, just bcos I was frustrated that we are not making progress. But even if I would spend that much cash, I would still be lacking #2 & #3.

So, here's a new suggestion:

• We all donate a number of bucks towards someone we identify as knowledgeable in #2 & #3. That person could then buy a USB analyzer from our donation and provide a true solution.

• As reward for the effort, that person now owns a USB analyzer

Any thoughts on this?

I can contribute, i can put 50/100€. But Motu seems to be interested in solving the problem...

"Hi Piermarco,

I am sorry to hear about all the issues you have been having with linux. I am an engineer at MOTU and I have been working on and off with Takashi Iwai, the maintainer of the snd-usb-audio to try and improve our compatibility with the linux kernel. We have already made some changes made that were incorporated into the 5.11 kernel, but there are still issues for sure. I have been working on resolving those, but the work is still in progress. If you still have this hardware and can build and test kernel modules, would you be interested in testing some patches?

Best,

Dylan"

[shellwalker]

I can contribute, i can put 50/100€. But Motu seems to be interested in solving the problem...

"Hi Piermarco,

I am sorry to hear about all the issues you have been having with linux. I am an engineer at MOTU and I have been working on and off with Takashi Iwai, the maintainer of the snd-usb-audio to try and improve our compatibility with the linux kernel. We have already made some changes made that were incorporated into the 5.11 kernel, but there are still issues for sure. I have been working on resolving those, but the work is still in progress. If you still have this hardware and can build and test kernel modules, would you be interested in testing some patches?

Best,

Dylan"

WOW!!!! Now THAT is really good news! And MOTU working with Takashi Iwai means they seem to be taking this seriously.
So, let's put my "analyzer idea" aside for now.

I am also willing to support MOTUs effort by testing with my equipment. Could you please get me connected? I believe we should have strictly defined test-scenarios, so that we are sure of what we are covering.

Maybe MOTU has a beta tester channel/community or similar that we could join? Let us seize this opportunity and affirm to MOTU that they have made the right decision by giving them strong constructive community support.

[baptiste]

If some help is needed to test the module, i'd be very happy to help. I bought my Ultralite AVB (non-ess) hoping that it would be my last sound card in decades, and suddenly this sounds achievable !

[buonamorte.records]

Hi @shellwalker and hi @baptiste ,

Yeah I think it's a great possibility! I'll ask to Dylan if i can share the patch with the community or a little testing team. What do you think about how a testing-paper should be in this case? System and OS info, behavior with ALSA, Jack, Pulse, Pipewire, working on a project on a daw and? Maybe an lsusb or other commands?

[bluebell]

If some help is needed to test the module, i'd be very happy to help. I bought my Ultralite AVB (non-ess) hoping that it would be my last sound card in decades, and suddenly this sounds achievable !

The non-ess works perfectly in Class Compliant mode with Drumfix' ua101-replacement, see viewtopic.php?f=6&t=18046&p=122814#p122814

[buonamorte.records]

Hi @bluebell ,
I own an ess version...it doesn't work with ua101 neither with dkms driver or kernel compilation...

[buonamorte.records]

Dylan from Motu:

"No problem! - I am not opposed to sharing the patch with others, with the caveat that it isn't a completely tested solution, and I welcome their feedback.

For more detailed information, the reason that older firmware's worked, was that we used to support a USB synchronization profile called "explicit feedback", this was deprecated in favor of "implicit feedback" synchronization (which is the preferred method according to Apple). Unfortunately, until very recently, linux could only support implicit feedback if a specific quirk flag was set in the ALSA driver. The 5.11 improvement was the result of Takashi and I working to make linux detect the implicit feedback mode automatically. So now the driver actually tries to stay synchronized in the correct way without needing the quirk. However, unfortunately, the implicit feedback implementation has this issue where it doesn't pre-schedule any transfers, resulting in xHCI isoc trb ring underruns and as a result, hardware underruns (glitchy sound!). This patch simply waits a bit on startup to accumulate a few input packets, then submit the output packets with the correct size cadence. It has the potential to increase the RTL latency, so if this solves the problem, the next step will be to see if we made a negative impact there, and try to fix that too."

I'm sending this patch via pvt message

[shellwalker]

I would never touch a motu, if I would get one for free I would try to sell it as soon as possible.
The attitude of motu towards linux is one thing.
The attitude of motu towards marketing and wording and making wierd promises is another thing.
pip pip

Hi artix_linux_user,
Yes, we want to stay alert.

BUT: see MOTUs newest response to buonamorte. That Dylan is giving full insight into the technical issue and he is actually working with Tikashi Iwai (a name you should recognize if you've been around Linux and Sound for a while) on this.

So, I prefer that we all regard this as a turning point and give MOTU the chance to make positive experience with Linux and its community. If that Dylan from MOTU can report positive response to his manager and make progress quickly bcos the Linux community is helping, then that could change MOTUs attitude towards Linux as a whole.

It's a give-and-take thing. In this particular field, Linux is not the lead (no need to debate, even though we are all lovers of Linux). You can see from Dylans response who drove the decision to switch from explicit to implicit feedback. That is reality. Let's face it ..... and change it!

[shellwalker]

Dylan from Motu:

"No problem! - I am not opposed to sharing the patch with others, with the caveat that it isn't a completely tested solution, and I welcome their feedback.

....

I'm sending this patch via pvt message

Thank you so much Buonamorte.records!!!! Thanks for getting the MOTU contact, thanks for having asked them yet again and thanks for getting us involved!

This is sounding very promising and the best thing I've seen for a long time since I joined this thread!!

[shellwalker]

What do you think about how a testing-paper should be in this case? System and OS info, behavior with ALSA, Jack, Pulse, Pipewire, working on a project on a daw and? Maybe an lsusb or other commands?

That already sounds good. To make reporting easier, foster reproducibility and also ensure common reporting format, I'd suggest we try to avoid manual steps as much as possible.
Ideally we should have a testing tool that we all could use and that gathers whatever technical information is required for describing the test environment, then executes a series of tests automatically and generates a report.
I believe that we really need only test at the very lowest level (=Alsa). Pulse, Jack, DAWs all build up on top of Alsa. I can imagine that creating a script that sets up a loopback connection in the MOTU card and feeds that loopback with "known" data in order to compare the output should be possible. That way we can even leave the tool running at lengths without manual monitoring.

[baptiste]

The non-ess works perfectly in Class Compliant mode with Drumfix' ua101-replacement, see viewtopic.php?f=6&t=18046&p=122814#p122814

Nope. I reinstalled drumfix' module as per instructions on github, curl'ed the motu to cc mode. About 2 hours later, i had a 8 channel hop.
usb-devices shows that the system uses the motu driver for the actual device.
I always had channel hop and/or progressive decimation/bitcrushing. It may take 5 min or 2 days, but it always happens.

[stanlea]

The non-ess works perfectly in Class Compliant mode with Drumfix' ua101-replacement, see viewtopic.php?f=6&t=18046&p=122814#p122814

Nope. I reinstalled drumfix' module as per instructions on github, curl'ed the motu to cc mode. About 2 hours later, i had a 8 channel hop.
usb-devices shows that the system uses the motu driver for the actual device.
I always had channel hop and/or progressive decimation/bitcrushing. It may take 5 min or 2 days, but it always happens.

It seems to work for some, but not for all. Drumfix patch was certainly a progress, but not "the" solution. I dit try it on my 828ES and it didn't do much. This said I can work with my unit, just have to reboot from time to time. A real solution would be a driver made with Motu's help for all models, with explicit or implicit feedback, which may not be the only issue.

[buonamorte.records]

Dylan:

"Hmm, it would be good to locate the “MOTU Patch” log in dmesg to confirm the patch is there. The log will be emitted when an audio stream is started, so usually what I do is watch dmesg while I start playback using “sudo dmesg -w”.The following command will add a lot of useful debugging information to the kernel log as well. This needs to be run after the snd-usb-audio module is already loaded. It needs to be rerun if the module is ever removed and reinserted, otherwise the logs will not show.

sudo sh -c 'echo "module snd_usb_audio +p" > /sys/kernel/debug/dynamic_debug/control'

You may need to mount the debugfs first.

mount -t debugfs none /sys/kernel/debug/"

@shellwalker It's a great pleasure for me to be useful for this great community! I hope that, after that experience, we can just make music with Linux!

@artix_linux_user I love the ess converters, the motu preamps, the interface usable also from a tablet in the network, the possibility to expand the network in a really useful way. Did RME ever demonstrated interest in developing a driver for our community? Do you have other and better example?

I'm testing the patch, see you later!

[buonamorte.records]

@stanlea do you want to test the patch from motu?

[stanlea]

Yes, absolutly, if it's not too hard technically. I have a 828ES "old model".