If you follow back to the start of the thread, I shared some error messages and a link where someone pointed out that the device doesn't follow the USB spec. Not sure of the relevance.
When the sound quits, the computer is generally responsive.
Here's some output about the interrupts. The interface is on Bus 03 / Port 3 / Dev 8 hence xhci_hcd.
antony@cubase:~$ lsusb -t && grep -E "(CPU|xhci)" /proc/interrupts
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 4, Class=Application Specific Interface, Driver=, 12M
|__ Port 3: Dev 8, If 6, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 7, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 4: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 4: Dev 4, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 4, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 7: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 8: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 8: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
CPU0 CPU1 CPU2 CPU3
29: 1488 1092584730 0 0 IR-PCI-MSI 327680-edge xhci_hcd
Nothing else is using that USB port.
Whilst reading around the points you raised, I found irqbalance. I see it is installed by default and running (not sure if that's a good thing, it sounds like a good idea to balance interrupts across all cores).
I also found this rather old thread when trying to find out how to get information about USB port priority: https://ubuntuforums.org/showthread.php?t=2184466. Shame he didn't post here, he might have gotten a response.
On 14 April 2017 at 23:02, Len Ovens <len@xxxxxxxxxxxxx> wrote:
On Fri, 14 Apr 2017, Antony Gelberg wrote:
Sorry, I can't quote easily (using Gmail on the web)...
About underruns, I'm using 128 frames / period and 2 periods / buffer. Now I'm
trying to reproduce the issue without jackd, I guess that might be less relevant.
The "operations" I was talking about can hardly be called massive, and the
lockups last for much longer than the operations themselves.
it's a pretty decent i5, nothing earth-shattering, but then I'm not asking much
of it. The lockups happen even without Ardour, just listening to music with
Audacious / VLC / Chrome (YouTube) / listening to old demos on Audacity.
Shouldn't happen. I would think.
Not sure if this has been asked before. WHere is the priority of the USB port in use? (as compared to other USB ports for example) The question is:
What is going causing the delay? Sound device going to sleep? (or reconnecting maybe? - does dmesg show it connecting more than once?) or the computer having some other process taking over for too long. I assume that there is no mouse/keyboard/etc. using the same USB port. Does the computer itself seem unresponsive when the sound quits?
Is it possible to test this device with a MAC or windows machine?
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
