14 Apr
2017
14 Apr
'17
9:17 p.m.
On Fri, April 14, 2017 1:26 pm, Antony Gelberg wrote:
I have noticed that the lockups seem to *start* when I
do
something that might cause a bit of processor / disk IO e.g.
Is it just underruns because the machine can't keep up? What number of
frames per period are you using, and how many periods per buffer?
Does ulimit -r show that you can set a high enough real time priority?
only happens when jack(dbus) is also running
Did you ever try jackd only without the pulse-sink loaded?
--
Chris Caudle
14 Apr
14 Apr
9:43 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
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.
antony@cubase:~$ sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 532 MB in 3.00 seconds = 177.30 MB/sec
antony@cubase:~$ sudo hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 23756 MB in 2.00 seconds = 11889.97 MB/sec
At the moment, the jury's still out on whether the lockups happen without
jackd. Currently running without it and will report back either way.
On 14 April 2017 at 22:16, Chris Caudle <chris(a)chriscaudle.org> wrote:
On Fri, April 14, 2017 1:26 pm, Antony Gelberg wrote:
--
http://www.linkedin.com/in/antgel
http://about.me/antonygelberg
I have noticed that the lockups seem to *start*
when I do
something that might cause a bit of processor / disk IO e.g.
Is it just underruns because the machine can't keep up? What number of
frames per period are you using, and how many periods per buffer?
Does ulimit -r show that you can set a high enough real time priority?
only happens when jack(dbus) is also running
Did you ever try jackd only without the pulse-sink loaded?
--
Chris Caudle
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:02 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
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
10:39 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
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.
I don't have a Mac or Windows machine to test with.
On 14 April 2017 at 23:02, Len Ovens <len(a)ovenwerks.net> wrote:
On Fri, 14 Apr 2017, Antony Gelberg wrote:
Sorry, I can't quote easily (using Gmail on the web)...
--
http://www.linkedin.com/in/antgel
http://about.me/antonygelberg
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:06 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
On Fri, 14 Apr 2017 23:38:55 +0300, Antony Gelberg wrote:
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).
https://wiki.archlinux.org/index.php/Professional_audio#Tips_and_Tricks
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/ht…
11:14 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
After reading those links, I don't draw any new conclusions with regard to
the issue I'm facing.
On 15 April 2017 at 00:06, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
On Fri, 14 Apr 2017 23:38:55 +0300, Antony Gelberg
wrote:
--
http://www.linkedin.com/in/antgel
http://about.me/antonygelberg
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).
https://wiki.archlinux.org/index.php/Professional_audio#Tips_and_Tricks
https://access.redhat.com/documentation/en-US/Red_Hat_
Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-
Realtime_Tuning_Guide-General_System_Tuning-Interrupt_and_
Process_Binding.html
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:47 p.m.
New subject: Lexicon Lambda USB - are my lockups due to the hardware or software?
On Fri, 14 Apr 2017, Chris Caudle wrote:
pactl unload-module module-jackdbus-detect
will unload the bridge on the fly.
--
Len Ovens
www.ovenwerks.net
only happens
when jack(dbus) is also running
Did you ever try jackd only without the pulse-sink loaded?
3000
days inactive
3000
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Antony Gelberg -
Chris Caudle -
Len Ovens -
Ralf Mardorf