* usb audio problems
@ 2003-08-29 19:25 np
0 siblings, 0 replies; 13+ messages in thread
From: np @ 2003-08-29 19:25 UTC (permalink / raw)
To: alsa-devel
hello list,
i'm crossposting this problem because it looks like it may be something more
suited to the developers list. i'm having some problems getting sound to
play through my emagic emi 2|6 usb soundcard. i've set up my internal sound
card on slot 0, and the emi on slot 1. modules are loaded fine according to
lsmod, and alsamixer seems to recognize the card fine. playing sound through
the internal soundcard works fine, but when i attempt to use the emi card
(with pd -alsadev 2) i get the following error messages:
couldn't open MIDI input device 1
couldn't open MIDI output device 1
opened 0 MIDI input device(s) and 0 MIDI output device(s).
snd_pcm_hw_params_set_format (input): Invalid argument
snd_pcm_hw_params_set_format (input): Invalid argument
ALSA lib pcm_hw.c:466:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE failed:
Invalid argument
snd_pcm_hw_params (input): Invalid argument
ALSA lib pcm_hw.c:466:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE failed:
Invalid argument
ALSA lib pcm.c:1146:(snd_pcm_link) SNDRV_PCM_IOCTL_LINK failed: File
descriptor in bad state
ALSA lib pcm_hw.c:494:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: File
descriptor in bad state
snd_pcm_start: File descriptor in bad state
Using ALSA interface
audio I/O stuck... closing audio
could anyone here help diagnose what the problem is? i'm running debian sid
on a 2.4.22 kernel, latest version of alsa. for the record, my lsmod shows:
snd-usb-audio 44176 0
snd-rawmidi 15952 0 [snd-usb-audio]
snd-seq-device 5000 0 [snd-rawmidi]
snd-powermac 34996 0
i2c-core 14324 0 [snd-powermac]
snd-pcm 66180 0 [snd-usb-audio snd-powermac]
snd-timer 16580 0 [snd-pcm]
snd-page-alloc 4964 0 [snd-pcm]
snd 35416 0 [snd-usb-audio snd-rawmidi snd-seq-device
snd-powermac snd-pcm snd-timer]
soundcore 4168 0 [snd]
ds 8268 1
yenta_socket 11792 1
pcmcia_core 44232 0 [ds yenta_socket]
ieee1394 49920 0 (unused)
emi26 162192 0 (unused)
any help would be appreciated!
thanks,
nick
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 13+ messages in thread
* USB Audio problems
@ 2003-11-19 19:28 Karim Yaghmour
2003-11-20 5:50 ` Karim Yaghmour
0 siblings, 1 reply; 13+ messages in thread
From: Karim Yaghmour @ 2003-11-19 19:28 UTC (permalink / raw)
To: alsa-devel
I've been trying to fix some problems I'm getting with the USB audio
driver.
Basically, I get these types of messages over and over accompanied
by some audio glitches:
ALSA usbaudio.c:688: cannot submit datapipe for urb 0, err = -6
usb-uhci.c: ENXIO 00038200, flags 2, urb cf74f5c0, burb cf74f5c0
I've been able to reproduce this problem on quite a few different
systems, including different architectures. The problems seem to
occur much more often on slower machines than on faster machines.
Basically, I've been able to identify that this is due to the
Linux USB layer checking whether the urb->hcpriv field being NULL
in the *_submit_urb() code and returning -EINVAL if it's not. In
other words, the URBs used by the USB audio driver are reused
prior to being cosumed.
I've instrumented the usbaudio driver using the Linux Trace Toolkit
to get some info about the behavior of start_urbs() and
snd_complete_urb(). I've also added a trace point at the same place
where the printk for "cannot submit datapipe for ubr" is called.
Here's what I get (note where "Abusing URB" is happening):
Event creation 4,867,640,107 N/A 391 NEW EVENT TYPE : Start URB; CUSTOM EVENT ID : 24
Event creation 4,867,640,138 N/A 391 NEW EVENT TYPE : Complete URB; CUSTOM EVENT ID : 25
Event creation 4,867,640,260 N/A 391 NEW EVENT TYPE : Abuse URB; CUSTOM EVENT ID : 26
Start URB 4,869,110,362 90 33 Sending URB 0
Start URB 4,869,110,606 90 33 Sending URB 1
Start URB 4,869,110,728 90 33 Sending URB 2
Start URB 4,869,110,850 90 33 Sending URB 3
Start URB 4,869,110,972 90 33 Sending URB 4
Complete URB 4,869,124,063 0 36 Completing URB 0
Complete URB 4,869,128,000 0 36 Completing URB 1
Complete URB 4,869,132,058 0 36 Completing URB 2
Complete URB 4,869,135,995 0 36 Completing URB 3
Complete URB 4,869,140,023 0 36 Completing URB 4
Complete URB 4,869,144,051 0 36 Completing URB 0
Complete URB 4,869,147,987 0 36 Completing URB 1
Complete URB 4,869,152,015 0 36 Completing URB 2
Complete URB 4,869,156,043 0 36 Completing URB 3
Complete URB 4,869,160,010 0 36 Completing URB 4
Complete URB 4,869,164,038 0 36 Completing URB 0
Complete URB 4,869,168,066 0 36 Completing URB 1
Complete URB 4,869,172,003 0 36 Completing URB 2
Complete URB 4,869,176,031 0 36 Completing URB 3
Complete URB 4,869,180,059 0 36 Completing URB 4
Complete URB 4,869,183,995 0 36 Completing URB 0
Complete URB 4,869,188,054 0 36 Completing URB 1
Complete URB 4,869,192,021 0 36 Completing URB 2
Complete URB 4,869,196,018 0 36 Completing URB 3
Complete URB 4,869,200,046 0 36 Completing URB 4
Complete URB 4,869,204,013 0 36 Completing URB 0
Complete URB 4,869,208,011 0 36 Completing URB 1
Complete URB 4,869,212,039 0 36 Completing URB 2
Complete URB 4,869,216,006 0 36 Completing URB 3
Complete URB 4,869,220,003 0 36 Completing URB 4
Complete URB 4,869,224,001 0 36 Completing URB 0
Complete URB 4,869,227,998 0 36 Completing URB 1
Complete URB 4,869,231,996 0 36 Completing URB 2
Complete URB 4,869,235,993 0 36 Completing URB 3
Complete URB 4,869,240,021 0 36 Completing URB 4
Complete URB 4,869,244,019 0 36 Completing URB 0
....
Complete URB 4,870,112,025 0 36 Completing URB 3
Complete URB 4,870,116,022 0 36 Completing URB 4
Complete URB 4,870,120,020 0 36 Completing URB 0
Complete URB 4,870,124,017 0 36 Completing URB 1
Complete URB 4,870,128,015 0 36 Completing URB 2
Complete URB 4,870,132,043 0 36 Completing URB 3
Complete URB 4,870,136,040 0 36 Completing URB 4
Complete URB 4,870,140,038 0 36 Completing URB 0
Complete URB 4,870,144,035 0 36 Completing URB 1
Start URB 4,870,145,378 90 33 Sending URB 0
Start URB 4,870,145,531 90 33 Sending URB 1
Start URB 4,870,145,653 90 33 Sending URB 2
Start URB 4,870,145,744 90 33 Sending URB 3
Start URB 4,870,145,866 90 33 Sending URB 4
Complete URB 4,870,148,063 0 36 Completing URB 2
Complete URB 4,870,152,061 0 36 Completing URB 3
Complete URB 4,870,156,058 0 36 Completing URB 4
Complete URB 4,870,159,049 0 36 Completing URB 0
Complete URB 4,870,160,056 0 36 Completing URB 0
Complete URB 4,870,163,046 0 36 Completing URB 1
Complete URB 4,870,164,053 0 36 Completing URB 1
Complete URB 4,870,167,044 0 36 Completing URB 2
Complete URB 4,870,168,020 0 36 Completing URB 2
Complete URB 4,870,171,041 0 36 Completing URB 3
...
Complete URB 4,871,171,087 0 36 Completing URB 3
Complete URB 4,871,172,063 0 36 Completing URB 0
Complete URB 4,871,175,054 0 36 Completing URB 4
Complete URB 4,871,176,061 0 36 Completing URB 1
Complete URB 4,871,179,051 0 36 Completing URB 0
Complete URB 4,871,180,089 0 36 Completing URB 2
Complete URB 4,871,180,364 0 36 Completing URB 0
Complete URB 4,871,181,127 0 36 Completing URB 1
Complete URB 4,871,182,103 0 36 Completing URB 3
Complete URB 4,871,183,079 0 36 Completing URB 1
Complete URB 4,871,183,202 0 36 Completing URB 4
Start URB 4,871,184,300 90 33 Sending URB 0
Start URB 4,871,184,483 90 33 Sending URB 1
Start URB 4,871,184,605 90 33 Sending URB 2
Start URB 4,871,184,697 90 33 Sending URB 3
Start URB 4,871,184,819 90 33 Sending URB 4
Start URB 4,871,186,833 90 33 Sending URB 0
Start URB 4,871,186,985 90 33 Sending URB 1
Start URB 4,871,187,138 90 33 Sending URB 2
Abuse URB 4,871,187,169 90 33 Abusing URB 2
Complete URB 4,871,204,410 90 36 Completing URB 2
Complete URB 4,871,205,173 0 36 Completing URB 3
Complete URB 4,871,205,295 0 36 Completing URB 4
Complete URB 4,871,205,447 0 36 Completing URB 0
Complete URB 4,871,205,722 0 36 Completing URB 0
Complete URB 4,871,205,935 0 36 Completing URB 1
Complete URB 4,871,206,180 0 36 Completing URB 1
Complete URB 4,871,207,095 90 36 Completing URB 2
Start URB 4,871,207,736 90 33 Sending URB 0
Start URB 4,871,207,858 90 33 Sending URB 1
Start URB 4,871,207,949 90 33 Sending URB 2
Start URB 4,871,208,071 90 33 Sending URB 3
Start URB 4,871,208,194 90 33 Sending URB 4
Complete URB 4,871,210,116 0 36 Completing URB 3
Complete URB 4,871,214,083 0 36 Completing URB 4
Complete URB 4,871,218,111 0 36 Completing URB 0
Complete URB 4,871,221,071 0 36 Completing URB 0
Complete URB 4,871,222,078 0 36 Completing URB 1
Complete URB 4,871,225,068 0 36 Completing URB 1
Complete URB 4,871,226,075 0 36 Completing URB 2
Complete URB 4,871,229,066 0 36 Completing URB 2
Complete URB 4,871,230,073 0 36 Completing URB 3
Complete URB 4,871,233,063 0 36 Completing URB 3
Complete URB 4,871,234,070 0 36 Completing URB 4
Complete URB 4,871,237,061 0 36 Completing URB 4
Complete URB 4,871,238,068 0 36 Completing URB 0
Complete URB 4,871,241,058 0 36 Completing URB 0
...
Complete URB 4,871,716,089 0 36 Completing URB 0
Complete URB 4,871,717,096 0 36 Completing URB 4
Complete URB 4,871,720,087 0 36 Completing URB 1
Complete URB 4,871,721,094 0 36 Completing URB 0
Complete URB 4,871,724,084 0 36 Completing URB 2
Complete URB 4,871,725,091 0 36 Completing URB 1
Complete URB 4,871,728,082 0 36 Completing URB 3
Complete URB 4,871,729,089 0 36 Completing URB 2
Complete URB 4,871,730,187 0 36 Completing URB 2
Start URB 4,871,731,377 90 33 Sending URB 0
Abuse URB 4,871,731,408 90 33 Abusing URB 0
Complete URB 4,871,748,741 90 36 Completing URB 4
Start URB 4,871,749,015 90 33 Sending URB 0
Abuse URB 4,871,749,046 90 33 Abusing URB 0
Complete URB 4,871,766,439 90 36 Completing URB 3
Complete URB 4,871,766,561 90 36 Completing URB 0
Complete URB 4,871,766,684 90 36 Completing URB 4
Complete URB 4,871,766,806 90 36 Completing URB 1
Complete URB 4,871,766,928 90 36 Completing URB 0
Complete URB 4,871,767,019 90 36 Completing URB 1
Complete URB 4,871,767,141 90 36 Completing URB 3
Start URB 4,871,767,294 90 33 Sending URB 0
Start URB 4,871,767,538 90 33 Sending URB 1
Start URB 4,871,767,629 90 33 Sending URB 2
Start URB 4,871,767,752 90 33 Sending URB 3
Start URB 4,871,767,843 90 33 Sending URB 4
Start URB 4,871,769,766 90 33 Sending URB 0
Start URB 4,871,769,918 90 33 Sending URB 1
Start URB 4,871,770,040 90 33 Sending URB 2
Start URB 4,871,770,162 90 33 Sending URB 3
Start URB 4,871,770,254 90 33 Sending URB 4
Complete URB 4,871,772,176 0 36 Completing URB 1
Complete URB 4,871,773,122 0 36 Completing URB 2
Complete URB 4,871,774,099 0 36 Completing URB 3
Complete URB 4,871,775,106 0 36 Completing URB 4
Start URB 4,871,775,899 90 33 Sending URB 0
Abuse URB 4,871,775,960 90 33 Abusing URB 0
Start URB 4,871,793,323 90 33 Sending URB 0
Abuse URB 4,871,793,384 90 33 Abusing URB 0
Complete URB 4,871,810,800 90 36 Completing URB 0
Complete URB 4,871,811,257 90 36 Completing URB 0
Complete URB 4,871,811,379 90 36 Completing URB 1
Complete URB 4,871,811,654 90 36 Completing URB 2
Complete URB 4,871,811,898 90 36 Completing URB 3
Complete URB 4,871,813,128 90 36 Completing URB 4
Start URB 4,871,819,109 90 33 Sending URB 0
Start URB 4,871,819,292 90 33 Sending URB 1
Start URB 4,871,819,414 90 33 Sending URB 2
Start URB 4,871,819,505 90 33 Sending URB 3
Start URB 4,871,819,627 90 33 Sending URB 4
Complete URB 4,871,824,113 0 36 Completing URB 0
Complete URB 4,871,828,080 0 36 Completing URB 1
Complete URB 4,871,832,078 0 36 Completing URB 2
Complete URB 4,871,833,085 0 36 Completing URB 0
Complete URB 4,871,836,075 0 36 Completing URB 3
Complete URB 4,871,837,082 0 36 Completing URB 1
Complete URB 4,871,840,073 0 36 Completing URB 4
Complete URB 4,871,841,080 0 36 Completing URB 2
Complete URB 4,871,844,070 0 36 Completing URB 0
...
[All the parts with "..." are events where there's only "Complete URB"
which happens.]
I'm using ALSA 0.9.6, but the problems do occur on later versiosns
still. This particular trace was collected on an ARM board.
Does anyone have any hints as to what I should be looking at.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-19 19:28 USB Audio problems Karim Yaghmour
@ 2003-11-20 5:50 ` Karim Yaghmour
2003-11-20 10:04 ` Niklas Werner
2003-11-20 13:57 ` Takashi Iwai
0 siblings, 2 replies; 13+ messages in thread
From: Karim Yaghmour @ 2003-11-20 5:50 UTC (permalink / raw)
To: alsa-devel
Well, it seems that I'm going to have to answer my own self ... :)
The following is what I've been able to find using additional tracing
info. Also there's a fix for usbaudio.c.
Basically, it's as I said before: the usbaudio driver uses URBs
without even checking if they're in use or not. Surprisingly, it
does this with one channel, but not the other. Here's what I get
in the traces when I separated the events by channel:
Channel A (the hex data is the value of *subs):
-----------------------------------------------------------------------------------
...
Complete URB 11,242,322,467 0 48 Completing URB 3: 0xC1F6040C
Complete URB 11,242,326,465 0 48 Completing URB 4: 0xC1F6040C
Complete URB 11,242,330,493 0 48 Completing URB 0: 0xC1F6040C
Complete URB 11,242,334,460 0 48 Completing URB 1: 0xC1F6040C
Complete URB 11,242,338,640 126 48 Completing URB 2: 0xC1F6040C
Start URB 11,242,338,945 126 45 Sending URB 0: 0xC1F6040C
Start URB 11,242,339,159 126 45 Sending URB 1: 0xC1F6040C
Start URB 11,242,339,342 126 45 Sending URB 2: 0xC1F6040C
Start URB 11,242,339,495 126 45 Sending URB 3: 0xC1F6040C
Abuse URB 11,242,339,617 126 45 Abusing URB 3: 0xC1F6040C
Deactivate URB 11,242,356,553 126 50 Deactivating URB 0: 0xC1F6040C
Complete URB 11,242,357,621 0 48 Completing URB 3: 0xC1F6040C
Complete URB 11,242,357,834 0 48 Completing URB 4: 0xC1F6040C
Complete URB 11,242,358,323 0 48 Completing URB 0: 0xC1F6040C
Complete URB 11,242,358,933 0 48 Completing URB 1: 0xC1F6040C
URB Active Mask 11,242,359,787 126 57 Active Mask NOT set for 1: 0xC1F6040C
Deactivate URB 11,242,359,970 126 50 Deactivating URB 2: 0xC1F6040C
Complete URB 11,242,360,611 0 48 Completing URB 2: 0xC1F6040C
URB Active Mask 11,242,361,008 126 57 Active Mask NOT set for 3: 0xC1F6040C
URB Active Mask 11,242,361,100 126 57 Active Mask NOT set for 4: 0xC1F6040C
Start URB 11,242,362,442 126 45 Sending URB 0: 0xC1F6040C
Start URB 11,242,362,656 126 45 Sending URB 1: 0xC1F6040C
Start URB 11,242,362,839 126 45 Sending URB 2: 0xC1F6040C
Start URB 11,242,362,991 126 45 Sending URB 3: 0xC1F6040C
Start URB 11,242,363,144 126 45 Sending URB 4: 0xC1F6040C
Complete URB 11,242,376,479 0 48 Completing URB 0: 0xC1F6040C
Complete URB 11,242,380,477 0 48 Completing URB 1: 0xC1F6040C
Complete URB 11,242,384,474 0 48 Completing URB 2: 0xC1F6040C
Complete URB 11,242,388,472 0 48 Completing URB 3: 0xC1F6040C
Complete URB 11,242,392,469 0 48 Completing URB 4: 0xC1F6040C
...
-----------------------------------------------------------------------------------
In this first channel, the deactivation function was never called at any
point prior to sending being initiated. Hence, a URB already in use was
reused without proper deactivation. Looking at the timestamps above, it
is clear that when sending is initiated on URB 3, this one is in its 4ms
playing period and would be interupted.
Channel B:
-----------------------------------------------------------------------------------
...
In the second channel, I had this:
Complete URB 11,242,319,446 0 48 Completing URB 4: 0xC1F6058C
Complete URB 11,242,323,474 0 48 Completing URB 0: 0xC1F6058C
Complete URB 11,242,327,472 0 48 Completing URB 1: 0xC1F6058C
Deactivate URB 11,242,330,767 126 50 Deactivating URB 0: 0xC1F6058C
Complete URB 11,242,331,500 0 48 Completing URB 2: 0xC1F6058C
Complete URB 11,242,331,713 0 48 Completing URB 0: 0xC1F6058C
Deactivate URB 11,242,331,896 126 50 Deactivating URB 1: 0xC1F6058C
Complete URB 11,242,332,537 0 48 Completing URB 1: 0xC1F6058C
URB Active Mask 11,242,332,720 126 57 Active Mask NOT set for 2: 0xC1F6058C
Deactivate URB 11,242,332,812 126 50 Deactivating URB 3: 0xC1F6058C
Complete URB 11,242,333,514 0 48 Completing URB 3: 0xC1F6058C
Deactivate URB 11,242,333,697 126 50 Deactivating URB 4: 0xC1F6058C
Complete URB 11,242,334,643 0 48 Completing URB 4: 0xC1F6058C
Start URB 11,242,335,833 126 45 Sending URB 0: 0xC1F6058C
Start URB 11,242,336,047 126 45 Sending URB 1: 0xC1F6058C
Start URB 11,242,336,199 126 45 Sending URB 2: 0xC1F6058C
Start URB 11,242,336,382 126 45 Sending URB 3: 0xC1F6058C
Start URB 11,242,336,535 126 45 Sending URB 4: 0xC1F6058C
Complete URB 11,242,357,987 0 48 Completing URB 0: 0xC1F6058C
Complete URB 11,242,358,628 0 48 Completing URB 1: 0xC1F6058C
Complete URB 11,242,359,168 0 48 Completing URB 2: 0xC1F6058C
Complete URB 11,242,361,557 126 48 Completing URB 3: 0xC1F6058C
Complete URB 11,242,365,555 0 48 Completing URB 4: 0xC1F6058C
Complete URB 11,242,369,522 0 48 Completing URB 0: 0xC1F6058C
...
-----------------------------------------------------------------------------------
In no occurence did the second channel reuse a URB prior to deactivating it.
Hence, there are no errors that ever occur on this channel.
To make a long story short, the most important issue here is to check whether
the URB is active before using it. If it is, then it must be unlinked first.
Here's my modified start_urbs() function from usbaudio.c:
static int start_urbs(snd_usb_substream_t *subs, snd_pcm_runtime_t *runtime)
{
unsigned int i;
int err;
for (i = 0; i < subs->nurbs; i++) {
snd_assert(subs->dataurb[i].urb, return -EINVAL);
/* Deactivate URB prior to using it. K.Y. */
if (test_and_clear_bit(i, &subs->active_mask)) {
set_bit(i, &subs->unlink_mask);
usb_unlink_urb(subs->dataurb[i].urb);
}
if (subs->ops.prepare(subs, runtime, subs->dataurb[i].urb) < 0) {
snd_printk(KERN_ERR "cannot prepare datapipe for urb %d\n", i);
goto __error;
}
}
if (subs->syncpipe) {
for (i = 0; i < SYNC_URBS; i++) {
snd_assert(subs->syncurb[i].urb, return -EINVAL);
if (subs->ops.prepare_sync(subs, runtime, subs->syncurb[i].urb) < 0) {
snd_printk(KERN_ERR "cannot prepare syncpipe for urb %d\n", i);
goto __error;
}
}
}
subs->running = 1;
for (i = 0; i < subs->nurbs; i++) {
trace_std_formatted_event(event_start_urb, i, (unsigned int) subs);
if ((err = usb_submit_urb(subs->dataurb[i].urb, GFP_KERNEL)) < 0) {
trace_std_formatted_event(event_abuse_urb, i, (unsigned int) subs);
snd_printk(KERN_ERR "cannot submit datapipe for urb %d, err = %d\n", i, err);
goto __error;
}
set_bit(i, &subs->active_mask);
clear_bit(i, &subs->unlink_mask);
}
if (subs->syncpipe) {
for (i = 0; i < SYNC_URBS; i++) {
if ((err = usb_submit_urb(subs->syncurb[i].urb, GFP_KERNEL)) < 0) {
snd_printk(KERN_ERR "cannot submit syncpipe for urb %d, err = %d\n", i, err);
goto __error;
}
set_bit(i + 16, &subs->active_mask);
}
}
return 0;
__error:
// snd_pcm_stop(subs->pcm_substream, SNDRV_PCM_STATE_XRUN);
deactivate_urbs(subs, 0);
return -EPIPE;
}
Using this code, I haven't had any more errors at all.
In order to use this, just remove all the trace_* functions. This new
function just checks if a URB is already in use prior to using it and
clears it. Also, it clears the unlink_mask after the call to
usb_submit_urb in order for it to be "clearable" by deactivate_urbs().
Without this last clear_bit(), URBs can only be cleared once by
deactivate_urbs() and it takes a new init_substream_urbs() to set the
entire mask back to 0. I don't see how this makes any sense.
Feedback is welcome.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 5:50 ` Karim Yaghmour
@ 2003-11-20 10:04 ` Niklas Werner
2003-11-20 11:10 ` Takashi Iwai
2003-11-20 20:25 ` Karim Yaghmour
2003-11-20 13:57 ` Takashi Iwai
1 sibling, 2 replies; 13+ messages in thread
From: Niklas Werner @ 2003-11-20 10:04 UTC (permalink / raw)
To: karim; +Cc: alsa-devel
Karim Yaghmour wrote:
>
> Well, it seems that I'm going to have to answer my own self ... :)
Yes, usb-audio seems to be a bit forgotten... (Takashi, those
mplayer-plughw-segfaults still persist, even on x86 and even with kernel
2.4 (current cvs of drivers/lib, of course)
>
> The following is what I've been able to find using additional tracing
> info. Also there's a fix for usbaudio.c.
>
hmmm, the submit_urb-error is gone, but random lockups and
usb-device-disconnect until reboot have come... (bitkeeper-2.6 from just
one hour ago...) with your function.
Have fun*
Niklas
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 10:04 ` Niklas Werner
@ 2003-11-20 11:10 ` Takashi Iwai
2003-11-20 20:25 ` Karim Yaghmour
1 sibling, 0 replies; 13+ messages in thread
From: Takashi Iwai @ 2003-11-20 11:10 UTC (permalink / raw)
To: Niklas Werner; +Cc: karim, alsa-devel
At Thu, 20 Nov 2003 11:04:52 +0100,
Niklas Werner wrote:
>
> Karim Yaghmour wrote:
>
> >
> > Well, it seems that I'm going to have to answer my own self ... :)
>
> Yes, usb-audio seems to be a bit forgotten... (Takashi, those
> mplayer-plughw-segfaults still persist, even on x86 and even with kernel
> 2.4 (current cvs of drivers/lib, of course)
not forgotten, but it's difficult to debug.
the problem is the behavior of submit_urb() and unlink_urb() is quite
dependent on the hub module and kernel version.
> >
> > The following is what I've been able to find using additional tracing
> > info. Also there's a fix for usbaudio.c.
> >
> hmmm, the submit_urb-error is gone, but random lockups and
> usb-device-disconnect until reboot have come... (bitkeeper-2.6 from just
> one hour ago...) with your function.
try async_unlink option. it's experimental but better for 2.6.
on 2.4 usb-uhci, it caused oops, though...
Takashi
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 5:50 ` Karim Yaghmour
2003-11-20 10:04 ` Niklas Werner
@ 2003-11-20 13:57 ` Takashi Iwai
2003-11-20 14:33 ` Patrick Shirkey
2003-11-20 20:28 ` Karim Yaghmour
1 sibling, 2 replies; 13+ messages in thread
From: Takashi Iwai @ 2003-11-20 13:57 UTC (permalink / raw)
To: karim; +Cc: alsa-devel
At Thu, 20 Nov 2003 00:50:03 -0500,
Karim Yaghmour wrote:
>
>
> Well, it seems that I'm going to have to answer my own self ... :)
>
> The following is what I've been able to find using additional tracing
> info. Also there's a fix for usbaudio.c.
>
> Basically, it's as I said before: the usbaudio driver uses URBs
> without even checking if they're in use or not. Surprisingly, it
> does this with one channel, but not the other. Here's what I get
> in the traces when I separated the events by channel:
> Channel A (the hex data is the value of *subs):
> -----------------------------------------------------------------------------------
(snip)
> To make a long story short, the most important issue here is to check whether
> the URB is active before using it. If it is, then it must be unlinked first.
>
> Here's my modified start_urbs() function from usbaudio.c:
> static int start_urbs(snd_usb_substream_t *subs, snd_pcm_runtime_t *runtime)
> {
> unsigned int i;
> int err;
>
> for (i = 0; i < subs->nurbs; i++) {
> snd_assert(subs->dataurb[i].urb, return -EINVAL);
> /* Deactivate URB prior to using it. K.Y. */
> if (test_and_clear_bit(i, &subs->active_mask)) {
> set_bit(i, &subs->unlink_mask);
> usb_unlink_urb(subs->dataurb[i].urb);
> }
> if (subs->ops.prepare(subs, runtime, subs->dataurb[i].urb) < 0) {
> snd_printk(KERN_ERR "cannot prepare datapipe for urb %d\n", i);
> goto __error;
> }
> }
> if (subs->syncpipe) {
> for (i = 0; i < SYNC_URBS; i++) {
> snd_assert(subs->syncurb[i].urb, return -EINVAL);
> if (subs->ops.prepare_sync(subs, runtime, subs->syncurb[i].urb) < 0) {
> snd_printk(KERN_ERR "cannot prepare syncpipe for urb %d\n", i);
> goto __error;
> }
> }
> }
>
> subs->running = 1;
> for (i = 0; i < subs->nurbs; i++) {
> trace_std_formatted_event(event_start_urb, i, (unsigned int) subs);
> if ((err = usb_submit_urb(subs->dataurb[i].urb, GFP_KERNEL)) < 0) {
> trace_std_formatted_event(event_abuse_urb, i, (unsigned int) subs);
> snd_printk(KERN_ERR "cannot submit datapipe for urb %d, err = %d\n", i, err);
> goto __error;
> }
> set_bit(i, &subs->active_mask);
> clear_bit(i, &subs->unlink_mask);
> }
> if (subs->syncpipe) {
> for (i = 0; i < SYNC_URBS; i++) {
> if ((err = usb_submit_urb(subs->syncurb[i].urb, GFP_KERNEL)) < 0) {
> snd_printk(KERN_ERR "cannot submit syncpipe for urb %d, err = %d\n", i, err);
> goto __error;
> }
> set_bit(i + 16, &subs->active_mask);
> }
> }
> return 0;
>
> __error:
> // snd_pcm_stop(subs->pcm_substream, SNDRV_PCM_STATE_XRUN);
> deactivate_urbs(subs, 0);
> return -EPIPE;
> }
>
> Using this code, I haven't had any more errors at all.
>
> In order to use this, just remove all the trace_* functions. This new
> function just checks if a URB is already in use prior to using it and
> clears it. Also, it clears the unlink_mask after the call to
> usb_submit_urb in order for it to be "clearable" by deactivate_urbs().
> Without this last clear_bit(), URBs can only be cleared once by
> deactivate_urbs() and it takes a new init_substream_urbs() to set the
> entire mask back to 0. I don't see how this makes any sense.
it'd be better to clean unlink_mask in the complete callback for the
case you use async unlink mode (see below).
and, the check of active_mask should be done in prepare callback, not
in the trigger callback. the trigger callback must be as short as
possible. we can put deactivate_urbs() in prepre callback so that the
urbs become clean before starting streams.
(but still we have a problem of async unlink because prepare callback
is also in the spinlocked context.)
the current code is surely buggy, because it issues sync unlink
inside the spinlocked context. it's problematic on 2.6 kernel or SMP
system, and may result in kernel oops. i added async_unlink module
option to change the behavior in the new version.
but it's still disabled as default, because unlinking multiple urbs
asynchronouly on 2.4 kernel causes kernel panic. sigh.
unfortunately, there is no perfect solution to satisfy all versions
yet. perhaps we need to redesign the linked-pcm streams to make it
possible to call prepare callback without spinlocks.
Takashi
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 13:57 ` Takashi Iwai
@ 2003-11-20 14:33 ` Patrick Shirkey
2003-11-21 15:21 ` Takashi Iwai
2003-11-20 20:28 ` Karim Yaghmour
1 sibling, 1 reply; 13+ messages in thread
From: Patrick Shirkey @ 2003-11-20 14:33 UTC (permalink / raw)
To: Takashi Iwai; +Cc: karim, alsa-devel
Takashi Iwai wrote:
>
> the current code is surely buggy, because it issues sync unlink
> inside the spinlocked context. it's problematic on 2.6 kernel or SMP
> system, and may result in kernel oops. i added async_unlink module
> option to change the behavior in the new version.
>
> but it's still disabled as default, because unlinking multiple urbs
> asynchronouly on 2.4 kernel causes kernel panic. sigh.
> unfortunately, there is no perfect solution to satisfy all versions
> yet. perhaps we need to redesign the linked-pcm streams to make it
> possible to call prepare callback without spinlocks.
>
>
Ahhh, Finally an explanaiton for why my root /var/ partition is always
being filled up with usb errors.
Would this also have a detrimental effect on latency? If so then I can
let other usb-audio user know why.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 10:04 ` Niklas Werner
2003-11-20 11:10 ` Takashi Iwai
@ 2003-11-20 20:25 ` Karim Yaghmour
1 sibling, 0 replies; 13+ messages in thread
From: Karim Yaghmour @ 2003-11-20 20:25 UTC (permalink / raw)
To: Niklas Werner; +Cc: alsa-devel
Niklas Werner wrote:
> hmmm, the submit_urb-error is gone, but random lockups and
> usb-device-disconnect until reboot have come... (bitkeeper-2.6 from just
> one hour ago...) with your function.
Interesting. I haven't seen any of these.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 13:57 ` Takashi Iwai
2003-11-20 14:33 ` Patrick Shirkey
@ 2003-11-20 20:28 ` Karim Yaghmour
2003-11-21 10:37 ` Takashi Iwai
1 sibling, 1 reply; 13+ messages in thread
From: Karim Yaghmour @ 2003-11-20 20:28 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
Takashi Iwai wrote:
> it'd be better to clean unlink_mask in the complete callback for the
> case you use async unlink mode (see below).
> and, the check of active_mask should be done in prepare callback, not
> in the trigger callback. the trigger callback must be as short as
> possible. we can put deactivate_urbs() in prepre callback so that the
> urbs become clean before starting streams.
Sounds right.
> (but still we have a problem of async unlink because prepare callback
> is also in the spinlocked context.)
Would it be fair to say that this driver requires some major rework?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 20:28 ` Karim Yaghmour
@ 2003-11-21 10:37 ` Takashi Iwai
0 siblings, 0 replies; 13+ messages in thread
From: Takashi Iwai @ 2003-11-21 10:37 UTC (permalink / raw)
To: karim; +Cc: alsa-devel
At Thu, 20 Nov 2003 15:28:25 -0500,
Karim Yaghmour wrote:
>
>
> Takashi Iwai wrote:
> > it'd be better to clean unlink_mask in the complete callback for the
> > case you use async unlink mode (see below).
> > and, the check of active_mask should be done in prepare callback, not
> > in the trigger callback. the trigger callback must be as short as
> > possible. we can put deactivate_urbs() in prepre callback so that the
> > urbs become clean before starting streams.
>
> Sounds right.
already changed on cvs :) will be reflected to 1.0.0-test2.
> > (but still we have a problem of async unlink because prepare callback
> > is also in the spinlocked context.)
>
> Would it be fair to say that this driver requires some major rework?
yes. not much in usbaudio.c itself but in the core PCM part.
Takashi
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
@ 2003-11-21 11:31 Denis de Leeuw Duarte
0 siblings, 0 replies; 13+ messages in thread
From: Denis de Leeuw Duarte @ 2003-11-21 11:31 UTC (permalink / raw)
To: alsa-devel
Hello list,
I'm new here so hi, and sorry if I missed out on things discussed earlier.
I subscribed to this list because I've been having lost of problems with
the USB driver over the past half year (similar to the stuff mentioned in
this thread). So much so, that I am prepared to dive into the code and
help fixing it.
> > (but still we have a problem of async unlink because prepare callback
> > is also in the spinlocked context.)
> Would it be fair to say that this driver requires some major rework?
Well, to give you an impression of the magnitude of the problem:
Last thursday I started Sweep, using my Quattro for output, and it
crashed. No big deal there, but not only did the crash lock up my
system, it also wiped out the better part of my root partition. That is
the kernel just randomly overwrote some files with junk. KDE was messed up
beyond repair, a number of files in /etc needed to be replaced and the
better part of the /root dir was clobbered. I had a gig the next day and I
run a source distro, so a quick reinstall was pretty much out of the
question. Needless to say, I did not have a lot of sleep that night :)
Although I understand that all parts of ALSA are important and deserve
attention, I would like to point out the impact of this situation: the
ALSA driver is (afaik?) the _only_ driver linux has for USB audio devices
(except speakers). Us usb users don't have the OSS drivers to fall back
on, so as long as the ALSA usb driver can wreck an installation, there
really is no decent support for USB audio in Linux. Anyway, just a
thought.
Meanwhile I'm doing my best to learn al I can about the ALSA drivers and
driver writing in general. Hopefully I'll be able to make a more
constructive contribution to this list in due time. Can anyone give me a
few hints on where the 'problematic' areas in the code are regarding USB?
So far I've heard about the core pcm stuff and the usb driver itself. Is
there any information (possibly written down somewhere) about the major
problem areas?
Regards,
Denis de Leeuw Duarte
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-20 14:33 ` Patrick Shirkey
@ 2003-11-21 15:21 ` Takashi Iwai
2003-11-21 16:50 ` Patrick Shirkey
0 siblings, 1 reply; 13+ messages in thread
From: Takashi Iwai @ 2003-11-21 15:21 UTC (permalink / raw)
To: Patrick Shirkey; +Cc: karim, alsa-devel
At Thu, 20 Nov 2003 23:33:52 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
> >
> > the current code is surely buggy, because it issues sync unlink
> > inside the spinlocked context. it's problematic on 2.6 kernel or SMP
> > system, and may result in kernel oops. i added async_unlink module
> > option to change the behavior in the new version.
> >
> > but it's still disabled as default, because unlinking multiple urbs
> > asynchronouly on 2.4 kernel causes kernel panic. sigh.
> > unfortunately, there is no perfect solution to satisfy all versions
> > yet. perhaps we need to redesign the linked-pcm streams to make it
> > possible to call prepare callback without spinlocks.
> >
> >
>
> Ahhh, Finally an explanaiton for why my root /var/ partition is always
> being filled up with usb errors.
>
> Would this also have a detrimental effect on latency? If so then I can
> let other usb-audio user know why.
no, it has nothing to do with the latency but oopsen / lock-up.
the problem exists only at stopping the streams. if the everything is
ok, it's not a big issue. but, when the device runs with small
latency, which may result in xrun often, has the higher probability to
hit this bug, because ALSA tries to stop the stream if xrun happens.
Takashi
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB Audio problems
2003-11-21 15:21 ` Takashi Iwai
@ 2003-11-21 16:50 ` Patrick Shirkey
0 siblings, 0 replies; 13+ messages in thread
From: Patrick Shirkey @ 2003-11-21 16:50 UTC (permalink / raw)
To: Takashi Iwai; +Cc: karim, alsa-devel
Takashi Iwai wrote:
>
>
> no, it has nothing to do with the latency but oopsen / lock-up.
> the problem exists only at stopping the streams. if the everything is
> ok, it's not a big issue. but, when the device runs with small
> latency, which may result in xrun often, has the higher probability to
> hit this bug, because ALSA tries to stop the stream if xrun happens.
>
Thanks. There should be a disclaimer somewhere for this problem.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-11-21 16:50 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-19 19:28 USB Audio problems Karim Yaghmour
2003-11-20 5:50 ` Karim Yaghmour
2003-11-20 10:04 ` Niklas Werner
2003-11-20 11:10 ` Takashi Iwai
2003-11-20 20:25 ` Karim Yaghmour
2003-11-20 13:57 ` Takashi Iwai
2003-11-20 14:33 ` Patrick Shirkey
2003-11-21 15:21 ` Takashi Iwai
2003-11-21 16:50 ` Patrick Shirkey
2003-11-20 20:28 ` Karim Yaghmour
2003-11-21 10:37 ` Takashi Iwai
-- strict thread matches above, loose matches on Subject: below --
2003-11-21 11:31 Denis de Leeuw Duarte
2003-08-29 19:25 usb audio problems np
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.