I haven't looked into the vendor mode issues yet, however the main implementation difference should be the number of channels. Hopefully any remediation to the class compliant mode will be applicable to the vendor mode as well.
nandoll wrote: ↑Thu Nov 24, 2022 11:50 pmOnce I get the jackd server started it runs fine. Initial startup is tricky. The input channels usually start with an 8xn offset from where they should be, I think output channels are normally fine (I check inputs only initially). Restarting jackd several times eventually gets them right, and after that I do not see channel hopping (at least it has never happened while I have been performing with the system). Very very occasionally I have seen weird distortion (high pitched periodic noise) which is one of the failure modes I have seen.
This is interesting, I haven't investigated the capture side as much as the playback side. Based on this report and a couple reports from @baptiste, I think there is also a failure mode related to the capture direction. I'm not sure how much you have gone between the class mode and vendor mode, but it would be interesting to know if there is a noticeable difference regarding the channel hop offset between the two modes.
Very neat to hear about these interesting use cases!
nandoll wrote: ↑Thu Nov 24, 2022 11:50 pmOne more datapoint:
I encountered this in our Listening Room system. A user with a Mac laptop, updated Motu drivers, and bad problems with channel hopping and noises of all kinds. I had never witnessed this with someone running OSX. Other users (different computers) did not report problems. The exact same hardware had been running for a long time. Replacing the USB cables fixed it! So, this points, as outlined before in the thread, to problems in Motu's firmware where it cannot recover from USB error conditions on its own (ie: problems are not only experienced in Linux).
This isn't too surprising. Based on my current understanding of the issue, the main difference with the Linux platform is that the USB isochronous stream experiences more interruptions than typically seen with our driver on windows or mac or the class driver on mac. The main focus of any firmware change is to make the device recover after such an interruption and the changes to the Linux driver are to try and prevent the interruptions in the first place.
nandoll wrote: ↑Fri Nov 25, 2022 1:31 ama) channel hopping and other glitchy behavior in class compliant mode:
there is a potential improvement when running a kernel with the snd-usb-audio-printk-6.0.3.patch, this would just use the snd-usb-audio driver
(latest version here: https://drive.google.com/file/d/1-00_qF ... v-rNr/view). This would also limit the channel count to what the current max is for the Motu firmware (24 channels), and potentially introduce a 12mS output latency penalty - to perhaps be solved in the future.
Yes, the latency issue should be solvable, this patch is mostly to see if improving the isoc scheduling improves the situation enough or if there are additional issues at play. I think its likely that the isoc scheduling is going to make the biggest difference, but I suspect there are some other situations that this doesn't address. I need to spend some time digging into the fallout around changing sampling rate and buffer size with different ALSA clients to understand more. I am suspicious that the class driver might be okay with introducing gaps in the isoc stream in some circumstances, which could create a problem for the hardware.
nandoll wrote: ↑Fri Nov 25, 2022 1:31 amb) better recovery from usb error conditions inside the Motu audio interface:
there may be test firmware images we could use, I would be happy to test those, time permitting (I can test on a Motu 8M or a 16A easily, while I could test on an UltraLite AVB this is not what I currently use).I could test a) and b), but this would not be really useful to me in "production" as...
Not addressed (yet? - cross fingers on this!) on this thread:
I started with the UltraLite and 24-Channel mode, but the general theory of the fix should apply to vendor mode as well. If the class mode changes are seeming like a step in the right direction, I can try to make a firmware that attempts to support both modes, I'll keep you posted.
nandoll wrote: ↑Fri Nov 25, 2022 1:42 amIf a) and b) solve (or ameliorate) the problems we see in class compliant mode, I imagine it would be possible to add the proper quirks to the kernel driver to point to the alternate endpoints that allow 64 channel transfers - module the patch in the kernel so that it does not complain about duplicated endpoints (I was doing that before using the full "motu" driver by Drumfix)...
I think this is likely the case.
@nandoll Do any of your host computers you use at Stanford support thunderbolt?
jkohls wrote: ↑Fri Nov 25, 2022 10:13 pmshellwalker wrote: ↑Thu Nov 24, 2022 3:13 pm
But I'm wondering: does anyone have an idea how we organize this whole patching & debugging information and the test-results in a better way? I'm afraid we'll soon lose overview...
Suggestions are welcome!I was thinking exactly the same thing. I ended up going out of town for Thanksgiving but now I'm back and still have time and motivation to contribute to this. My suggestion is we use any existing issue management system @AudioNarwhal is already using (if available to us) or whatever the Narwhal prefers.
This thread is going okay for me so far, but it may be nice to have something more issue-categorized. I think the main struggle I am having is to reproduce some of the various issues that are reported. Definitely system information (pcie devices, usb devices) and the kernel logs with dynamic debugging enabled are are super useful pieces of information.
shellwalker wrote: ↑Sat Nov 26, 2022 6:16 pmAudioNarwhal needs to state whether it's ok to stage the patch there and should state the license (which I am assuming to be GPL in order to be compliant with the kernel...).
Yeah, I hope for this to just result in a change for the USB audio class driver so it would maintain its current license.