23 Mar
2005
23 Mar
'05
10:11 p.m.
On 23/03/05 15:12:34, Ryan Gallagher wrote:
On Tue, 2005-03-22 at 10:08 -0500, Spencer Russell
wrote:
I am right in thinking the UA-25 used only standard USB Audio drivers? I can see nothing
om the kernel tree that looks specific to a UA-25.
Do people find these keyboard lockups occur with a variety of USB sound cards but not with
other USB devices? Perhaps people can e-mail me accordingly as it may give a clue as to
where that problem lies.
Wow, seems like you're having pretty much
exactly the same kinds
of troubles I've had, right down to the occasional keyboard
lockup. Maybe something strange with the via chipset?
Nope, keyboard lockups happen here too. And others have reported the
same, for me it's when I unplug my ua-25 so it's not card specific. I also suspected IRQ issues, and digging through
kernel-parameters.txt
brought me this boot option: acpi_irq_balance
I'll try this just in case it makes a difference.
Steve.
24 Mar
24 Mar
5:17 a.m.
New subject: [linux-audio-user] Tascam US-122, Laptop and Keyboard
Steve Fosdick wrote:
I am right in thinking the UA-25 used only standard
USB Audio
drivers?
Yes.
Do people find these keyboard lockups occur with a
variety of USB
sound cards but not with other USB devices?
USB Audio devices are somewhat different because they use isochronous
transfers. Video capture devices use those, too.
Regards,
Clemens
2:28 p.m.
New subject: [linux-audio-user] Tascam US-122, Laptop and Keyboard
On Thu, 2005-03-24 at 10:17 +0100, Clemens Ladisch wrote:
Steve Fosdick wrote:
Clemens (or any other informed reader),
Can you give me an idea of what these;
delay of 16535.000 usecs exceeds estimated spare time of 1307.000;
restart ...
Messages mean? Where do they originate? Are there any specific steps I
should take in getting rid of them? Is it somehow related to the fact
that this is a USB device?
Thanks in advance,
-ry
--
Ryan Gallagher <ruinaudio(a)comcast.net>
I am right in thinking the UA-25 used only
standard USB Audio
drivers?
Yes.
Do people find these keyboard lockups occur with
a variety of USB
sound cards but not with other USB devices?
USB Audio devices are somewhat different because they use isochronous
transfers. Video capture devices use those, too. 
2:49 p.m.
New subject: [linux-audio-user] Tascam US-122, Laptop and Keyboard
On Thu, 2005-03-24 at 06:17 -0600, Ryan Gallagher wrote:
On Thu, 2005-03-24 at 10:17 +0100, Clemens Ladisch
wrote:
It means JACK was delayed in waking up for more than half the period
time. For a PCI card this means the processing of the audio interrupt
was delayed for a long time.
With PCI cards this is a highly unusual and pathological situation. It
could be caused by a broken config like having the sound card IRQ
threaded but with a low RT priority. For a PCI card you will very
rately run into this situation.
I think the problem could be in the kernel or the ALSA driver. The
problem is related to the fact that it's a USB device, but it should be
possible to get this working (it works on other OS).
You are running at a pretty low latency (1.3ms or 64 frames at 48KHz).
But, since it looks like the wakeup delay is 16ms, as you probably know
you will have big problems running at any reasonable latency setting.
ISTR someone tried this config with Ingo's RT preempt kernel, and the
problem was still present? Maybe the latency tracing facility would
help.
Is the USB irq shared with anything?
Anyway, it's hard for me to diagnose the problem more without having the
hardware.
Lee
Steve Fosdick wrote:
Clemens (or any other informed reader),
Can you give me an idea of what these;
delay of 16535.000 usecs exceeds estimated spare time of 1307.000;
restart ...
Messages mean? Where do they originate? Are there any specific steps I
should take in getting rid of them? Is it somehow related to the fact
that this is a USB device? I am right in thinking the UA-25 used only
standard USB Audio
drivers?
Yes.
Do people find these keyboard lockups occur with
a variety of USB
sound cards but not with other USB devices?
USB Audio devices are somewhat different because they use isochronous
transfers. Video capture devices use those, too.
3:03 p.m.
New subject: [linux-audio-user] Tascam US-122, Laptop and Keyboard
On Thu, 2005-03-24 at 13:49 -0500, Lee Revell wrote:
Is the USB irq shared with anything?
Never mind, I see that it is shared, and with a pretty "heavy" device
(the network card).
Is this the case for everyone who is having the problem?
Does disconnecting the network cable help?
Lee
4:42 p.m.
New subject: [linux-audio-user] Tascam US-122, Laptop and Keyboard
On Thu, 2005-03-24 at 14:03 -0500, Lee Revell wrote:
On Thu, 2005-03-24 at 13:49 -0500, Lee Revell wrote:
There's two similar (except for hardware) user experiences being
reported here... in my case I was able to eliminate "shared IRQ" issues.
By issuing the "acpi_irq_balance" kernel parameter. Currently my irq
assignment is:
CPU0
0: 228818 XT-PIC timer 0/28818
1: 617 XT-PIC i8042 0/617
2: 0 XT-PIC cascade 0/0
7: 63 XT-PIC Intel 82801DB-ICH4, eth0 0/63
8: 2 XT-PIC rtc 0/2
9: 11329 XT-PIC acpi, radeon@pci:0000:01:00.0 0/11329
10: 727 XT-PIC uhci_hcd:usb2, ehci_hcd:usb4 0/727
11: 3 XT-PIC uhci_hcd:usb1, uhci_hcd:usb3, ohci1394
0/3
12: 13706 XT-PIC i8042 1/13706
14: 1701 XT-PIC ide0 0/1701
15: 5553 XT-PIC ide1 0/5553
It doesn't seem to matter what USB bus it's on (or for that matter if
irq's are "reshuffled" or not) so I'm suspicious of some intrinsic
kernel or driver issue (barring some weird hardware hangup). I've got
the week off so I'll do some further testing (I also have the builtin
ac97 chip and another USB device (emi 2|6).
Is the USB irq shared with anything?
Never mind, I see that it is shared, and with a pretty "heavy" device
(the network card). Is this the case for everyone who is having the
problem?
Does disconnecting the network cable help?
As reported above, eth0 is on another IRQ. Also all my kernels are
patched with Ingo Molnar's RP patches (2.6.8.1 through 2.6.12.rcX). I'm
unthreading whatever IRQ the device is on (10 or 11 and sometimes both).
thanks,
-ry
--
Ryan Gallagher <ruinaudio(a)comcast.net>
26 Mar
26 Mar
9:32 a.m.
New subject: [linux-audio-user] Success: Tascam US-122 and Laptop
On 24/03/05 19:03:50, Lee Revell wrote:
On Thu, 2005-03-24 at 13:49 -0500, Lee Revell wrote:
I had previously tried disconnecting the network cable but this didn't
seem to make any difference. I also tried the apci_irq_balance option
but that didn't solve it either.
I have finally got jackd to run without complain by disabling CPU
frequency scaling, i.e. having the CPU run at 1.2Ghz all the time rather
than switch to 600Mhz when it doesn't appear that there is anything
going on.
I wonder if this means the code path between the USB interrupt and jackd
being woken up is very long so as to require the full 1.2Ghz or whether
it is just a case of the frequency switching upsetting some time
calculations.
Steve.
Is the USB irq shared with anything?
Never mind, I see that it is shared, and with a pretty "heavy" device
(the network card).
Is this the case for everyone who is having the problem?
Does disconnecting the network cable help?
2:12 p.m.
New subject: [linux-audio-user] Success: Tascam US-122 and Laptop
On Sat, 2005-03-26 at 13:32 +0000, Steve Fosdick wrote:
On 24/03/05 19:03:50, Lee Revell wrote:
Oh, well, of course. JACK does not work with CPU frequency scaling.
You need to run it at full speed. This is something of a FAQ.
Lee
On Thu, 2005-03-24 at 13:49 -0500, Lee Revell
wrote:
I had previously tried disconnecting the network cable but this didn't
seem to make any difference. I also tried the apci_irq_balance option
but that didn't solve it either.
I have finally got jackd to run without complain by disabling CPU
frequency scaling, i.e. having the CPU run at 1.2Ghz all the time rather
than switch to 600Mhz when it doesn't appear that there is anything
going on.
I wonder if this means the code path between the USB interrupt and jackd
being woken up is very long so as to require the full 1.2Ghz or whether
it is just a case of the frequency switching upsetting some time
calculations. Is the USB irq shared with anything?
Never mind, I see that it is shared, and with a pretty "heavy" device
(the network card).
Is this the case for everyone who is having the problem?
Does disconnecting the network cable help?
7216
days inactive
7219
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Clemens Ladisch -
Lee Revell -
Ryan Gallagher -
Steve Fosdick