Re: [Alsa-devel] Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP
Jaroslav Kysela a écrit : On Thu, 29 Jan 2004, Thomas Charbonnel wrote: Hi, I noticed this problem today using midi on my setup (alsa 1.0.1, kernel 2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) : Debug: sleeping function called from invalid context at include/asm/uaccess.h:473 in_atomic():1, irqs_disabled():1 Call Trace: [c012139c] __might_sleep+0xac/0xe0 [c010b170] handle_signal+0xd0/0x140 [c03955ef] snd_rawmidi_kernel_read1+0x10f/0x170 [c03957e7] snd_rawmidi_read+0x147/0x1b0 [c01131cf] restore_i387_fxsave+0x8f/0xa0 [c015b2f3] vfs_read+0xd3/0x140 [c015b59f] sys_read+0x3f/0x60 [c010b4bb] syscall_call+0x7/0xb I'm sorry I didn't check if this was fixed in 1.0.2, but though it was worth mentioning. This caused regular (~ 1/second) dropouts in pd while using midi. I'm not sure, but it looks like kernel problem. We don't call handle_signal() function from snd_rawmidi_kernel_read1() - you may check this function - scheduling is not involved. I wonder why this function is called from in the spinlock context. Please, report this problem to LKML or try the latest 2.6 kernel. Jaroslav Hi Jaroslav, Doing some more tests I got also this message : Debug: sleeping function called from invalid context at include/asm/uaccess.h:498 in_atomic():1, irqs_disabled():1 Call Trace: [c012139c] __might_sleep+0xac/0xe0 [c0395c2d] snd_rawmidi_kernel_write1+0x16d/0x200 [c0395ea4] snd_rawmidi_write+0x1b4/0x300 [c010b2c1] do_signal+0xe1/0xf0 [c01131cf] restore_i387_fxsave+0x8f/0xa0 [c015b4f3] vfs_write+0xd3/0x140 [c015b5ff] sys_write+0x3f/0x60 [c010b4bb] syscall_call+0x7/0xb The kernel functions pointed to in include/asm/usaccess.h are copy_to_user and copy_from_user. They are indeed called from a spinlock context from both snd_rawmidi_kernel_write1 and snd_rawmidi_kernel_read1, and are flagged might_sleep. The strange thing is that they were already flagged might_sleep in 2.6.0, which I believe I compiled with CONFIG_DEBUG_SPINLOCK_SLEEP also, and I can't remember having the problem. On the other hand I only checked dmesg here because I could hear audio dropouts. Maybe the might_sleep detection code has been changed and is responsible for the dropouts ? Thomas --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] usx2yloader: us224 fix
Hi, our assumption in the usx2yloader for an US-224 was wrong (the prepad size differs). I've attached a patch which fix this in alsa-firmware. Instead of usx2y.prepad (which can be removed now) I've created two new prepad files for the usx2yloader: us122.prepad, us224.prepad. They should be copied to alsa-firmware/usx2yloader. Thanks to David Coulm for his help. martin --- us122.conf.ORIGINAL Sun Feb 1 12:18:26 2004 +++ us122.conf Sun Feb 1 12:19:02 2004 @@ -1,5 +1,5 @@ # boot firmwares for Tascam us122 deviceid 0x8007 -dsp0 usx2y.prepad +dsp0 us122.prepad dsp1 us122.rbt --- us224.conf.ORIGINAL Thu Jan 29 23:47:49 2004 +++ us224.conf Thu Jan 29 23:48:04 2004 @@ -1,5 +1,5 @@ # boot firmwares for Tascam us224 deviceid 0x8005 -dsp0 usx2y.prepad +dsp0 us224.prepad dsp1 us224.rbt --- Makefile.am.ORIGINALThu Jan 29 23:47:15 2004 +++ Makefile.am Sun Feb 1 12:21:39 2004 @@ -1,7 +1,7 @@ MYNAME = usx2yloader cfg_files =us122.conf us224.conf us428.conf \ - usx2y.prepad us428.prepad \ + us122.prepad us224.prepad us428.prepad \ us122.rbt us224.rbt us428.rbt \ tascam_loader.ihx \ us122fw.ihx us224fw.ihx us428fw.ihx us224.prepad Description: Binary data us122.prepad Description: Binary data
[Alsa-devel] dmix, dsnoop, asym weirdness [no errors, no sound either]
Ok, i have a hw mixing capable card, but i do have interest in getting
the dmix/dsnoop/asym thing working. Well, i defined a pasymed device
like this:
--.asoundrc start
#asym fun start here. we define one pcm device called dmixed
pcm.dmixed {
ipc_key 1025
type dmix
slave.pcm hw:0,0
}
#one called dsnooped for capturing
pcm.dsnooped {
ipc_key 1026
type dsnoop
slave.pcm hw:0,0
}
#and this is the real magic
pcm.asymed {
type asym
playback.pcm dmixed
capture.pcm dsnooped
}
#a quick plug plugin for above device to do the converting magic
pcm.pasymed {
type plug
slave.pcm asymed
}
#a ctl device to keep xmms happy
ctl.pasymed {
type hw
card 0
}
--.asoundrc end
Now i should be able to test that device pasymed with the aplay
command:
aplay -D pasymed foo.wav
This command does not give any error messages on my machine. It also
does not produce any sound. The soundfile is rather short and aplay
exits fine after the duration of the soundfile. So i figure it is played
back correctly. The question is though: Where is it played to? I have
three playback devices on my cs46xx soundcard:
[EMAIL PROTECTED]:~$ cat /proc/asound/devices
1: : sequencer
0: [0- 0]: ctl
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
17: [0- 1]: digital audio playback
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
33: : timer
But i have only one speaker pair connected to the soundcard outs. I just
tested the two analoge outs [don't have any digital equipment for
digital out]. The pasymed signal doesn't come out anywhere.. I think
it's a dmix issue, because
aplay -D plug:dmix foo.wav
shows the exact same behaviour [no errors, no sound, normal termination
after duration of soundfile].. dsnoop is behaving weirdly, too. I just
recorded with
arecord -D pasymed -t wav -f cd foo.wav
and it records just a little chunk of audio repeated over and over. It
seems to be the first period that is in the buffer after opening the
device [for i get a file filled with silence when i start recording at a
silent point]. I put up the .wav at
http://mistatapas.ath.cx:/foo.wav
I get the exact same result with
aplay -D plug:dsnooped -t wav -f cd foo.wav
Here's some more info about my setup:
[EMAIL PROTECTED]:~$ uname -a
Linux mango.fruits.de 2.4.22 #1 SMP Wed Nov 19 13:43:03 CET 2003 i686
GNU/Linux
[EMAIL PROTECTED]:~$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.1.
Compiled on Jan 22 2004 for kernel 2.4.22 (SMP) with versioned symbols.
[EMAIL PROTECTED]:~$ cat /proc/asound/cards
0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
Sound Fusion CS46xx at 0xcffef000/0xcfe0, irq 5
Flo
--
signature :)
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: still interested in us224 support?
Am Freitag, 30. Januar 2004 21:12 schrieb Martin Langer: On Fri, Jan 30, 2004 at 06:04:09PM +0100, David wrote: Le Jeudi 29 Janvier 2004 23:54, vous avez écrit : Jump to alsa-firmware/usx2yloader and place the attached us224.prepad file there. Part two of the job is patching two files there with the attached patchfile: patch -p0 loader.patch Done, but even a ./configure make make install would copy us224.prepad to /usr/local/share/alsa/firmware/usx2yloader/ so i copied the file by myself. ok. and then run the typical install stuff... Now the control led is burning. I couldn't force aplay to use us224 instead of my maestro 2E, so i tried to cat a wav file to /dev/dspx. I also tried to use xmms : it seems the file is played but with no sound. if the us224 is device number X: aplay -Dplughw:X,0 test.wav I guess it's in your case: aplay -Dplughw:1,0 test.wav For direct hardware access if the file is 44.1 or 48kHz and no alsa-lib conversion is necessary, it should be possible with: aplay -Dhw:1,0 test.wav running alsamixer -c1 returns a No mixer elems found (i think it's normal as under Windows there is also no mixing possibility). Well, that's the big difference to my 122 which is only an I/O interface and not a controller. My mixer is a 100% hardware solution but I guess the 224 is like the 428 and need a similar (the same ?) control interface. Perhaps the us428control (in alsa-tools) works out of the box for the 224 too, but I've never looked inside that code. Karsten? could work. but maybe some numbers identifying sliders or output mixers don't fit us224. we would need info from tasam or usb snooping windoze or braveheartedly testing on linux to know more. ...also i'm not completely shure if the snd-usb-usx2y's mmap interface is initialized for us224 also. us428control talks to the driver with it. Just give it a try. Karsten, how reacts the 428 without starting us428control? Simply no sound on playback? Or is there another point I've missed? No sound on playback. I guess it's time to create some official 224 driver/loader patches for Alsa CVS now. Any objections? You uncommented any section containing USB_ID_US224 in snd-usb-usx2y? Also for trying on us224 please change usbusx2yaudio.c line 1244 (usX2Y(card)-chip.dev-descriptor.idProduct == USB_ID_US428 to (usX2Y(card)-chip.dev-descriptor.idProduct == USB_ID_US224 have fun, Karsten --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Remote soundcards.
Hello. I have had this idea for some time now, and would like to ask you for your opinions on it. There are several solutions for sound transport. Software like esound, nas, arts etc. All those things have two common problems: 1. They're focused on pcm devices (lacks in mixer support etc) 2. They're not transparent for apps, no common API. 3. They suffer from lags. But we have a nice alsa API, we have support for multiple cards in alsa itself. Now how about developing a patch for alsa-lib, and a small daemon, which together could create a network transparent link, so that local apps (like xmms, mplayer, aumix, mixer_applet, pmidi etc) could use it as an ordinary soundcard? It would: 1. support all devices alsa supports (and their pcms, sequencers and mixers) 2. be usable for any alsa-compatible app 3. not suffer from lags (as a tool for LAN networks, we maybe could get away with soundcard's buffer), it would be usable for applications like Internet telephony (gnomemeeting etc) Who would need this? Linux gets more and more office desktop computers under it's control. Common solution (my company implements these too) are xterminals, dumb boxen with Xserver. There is a need for convenient usage of local devices from main server. for graphics/keyboard/mouse we have XFree86. But no decent solution for sound stuff!. What do you think about it? bye, Filip djMedrzec Zyzniewski --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Problems with gcc-3.4 / alsa-lib
Hello, I have tried to compile alsa-lib CVS with gcc-3.4 CVS and got the following error: gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -O2 -march=pentium4 -MT pcm_dmix.lo -MD -MP -MF .deps/pcm_dmix.Tpo -c pcm_dmix.c -fPIC -DPIC -o .libs/pcm_dmix.o pcm_dmix_i386.h: In function `mix_areas1': pcm_dmix_i386.h:45: error: PIC register `ebx' clobbered in `asm' pcm_dmix_i386.h: In function `mix_areas1_mmx': pcm_dmix_i386.h:163: error: PIC register `ebx' clobbered in `asm' pcm_dmix_i386.h: In function `mix_areas2': pcm_dmix_i386.h:245: error: PIC register `ebx' clobbered in `asm' pcm_dmix_i386.h: In function `mix_areas1_smp': pcm_dmix_i386.h:45: error: PIC register `ebx' clobbered in `asm' pcm_dmix_i386.h: In function `mix_areas1_smp_mmx': pcm_dmix_i386.h:163: error: PIC register `ebx' clobbered in `asm' pcm_dmix_i386.h: In function `mix_areas2_smp': pcm_dmix_i386.h:245: error: PIC register `ebx' clobbered in `asm' make[2]: *** [pcm_dmix.lo] Error 1 make[2]: Leaving directory `/sources/alsa-lib/src/pcm' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/sources/alsa-lib/src' make: *** [all-recursive] Error 1 I don't know enough gcc asm to fix this; any ideas? Florian Schanda --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP
Thomas Charbonnel wrote :
Jaroslav Kysela a écrit :
On Thu, 29 Jan 2004, Thomas Charbonnel wrote:
Hi,
I noticed this problem today using midi on my setup (alsa 1.0.1,
kernel 2.6.1 with CONFIG_DEBUG_SPINLOCK_SLEEP) :
Debug: sleeping function called from invalid context at
include/asm/uaccess.h:473
in_atomic():1, irqs_disabled():1
Call Trace:
[c012139c] __might_sleep+0xac/0xe0
[c010b170] handle_signal+0xd0/0x140
[c03955ef] snd_rawmidi_kernel_read1+0x10f/0x170
[c03957e7] snd_rawmidi_read+0x147/0x1b0
[c01131cf] restore_i387_fxsave+0x8f/0xa0
[c015b2f3] vfs_read+0xd3/0x140
[c015b59f] sys_read+0x3f/0x60
[c010b4bb] syscall_call+0x7/0xb
I'm sorry I didn't check if this was fixed in 1.0.2, but though it
was worth mentioning. This caused regular (~ 1/second) dropouts in pd
while using midi.
I'm not sure, but it looks like kernel problem. We don't call
handle_signal() function from snd_rawmidi_kernel_read1() - you may check
this function - scheduling is not involved. I wonder why this function is
called from in the spinlock context.
Please, report this problem to LKML or try the latest 2.6 kernel.
Jaroslav
Hi Jaroslav,
Doing some more tests I got also this message :
Debug: sleeping function called from invalid context at
include/asm/uaccess.h:498
in_atomic():1, irqs_disabled():1
Call Trace:
[c012139c] __might_sleep+0xac/0xe0
[c0395c2d] snd_rawmidi_kernel_write1+0x16d/0x200
[c0395ea4] snd_rawmidi_write+0x1b4/0x300
[c010b2c1] do_signal+0xe1/0xf0
[c01131cf] restore_i387_fxsave+0x8f/0xa0
[c015b4f3] vfs_write+0xd3/0x140
[c015b5ff] sys_write+0x3f/0x60
[c010b4bb] syscall_call+0x7/0xb
The kernel functions pointed to in include/asm/usaccess.h are
copy_to_user and copy_from_user. They are indeed called from a spinlock
context from both snd_rawmidi_kernel_write1 and
snd_rawmidi_kernel_read1, and are flagged might_sleep. The strange thing
is that they were already flagged might_sleep in 2.6.0, which I believe
I compiled with CONFIG_DEBUG_SPINLOCK_SLEEP also, and I can't remember
having the problem. On the other hand I only checked dmesg here because
I could hear audio dropouts. Maybe the might_sleep detection code has
been changed and is responsible for the dropouts ?
Thomas
Hi Jaroslav,
The attached patch fixes the problem for me, but I took the obvious and
easy way - I may have missed something.
Thomas
--- rawmidi.c.old 2003-10-23 16:34:52.0 +0200
+++ rawmidi.c 2004-02-01 15:04:15.0 +0100
@@ -909,10 +909,11 @@
if (kernel) {
memcpy(buf + result, runtime-buffer + runtime-appl_ptr,
count1);
} else {
+ spin_unlock_irqrestore(runtime-lock, flags);
if (copy_to_user(buf + result, runtime-buffer +
runtime-appl_ptr, count1)) {
- spin_unlock_irqrestore(runtime-lock, flags);
return result 0 ? result : -EFAULT;
}
+ spin_lock_irqsave(runtime-lock, flags);
}
runtime-appl_ptr += count1;
runtime-appl_ptr %= runtime-buffer_size;
@@ -1133,10 +1134,13 @@
if (kernel) {
memcpy(runtime-buffer + runtime-appl_ptr, buf, count1);
} else {
+ spin_unlock_irqrestore(runtime-lock, flags);
if (copy_from_user(runtime-buffer + runtime-appl_ptr, buf,
count1)) {
+ spin_lock_irqsave(runtime-lock, flags);
result = result 0 ? result : -EFAULT;
goto __end;
}
+ spin_lock_irqsave(runtime-lock, flags);
}
runtime-appl_ptr += count1;
runtime-appl_ptr %= runtime-buffer_size;
[Alsa-devel] Edirol UA-1X
Hallo, here's the second one of my current USB bulk messages: I'm trying to get the Edirol UA-1X to work, which I didn't find in the list of supported devices yet, so maybe this has some interesting information for driver developers. Plugging in the device into a 2.6.1 kernel with ALSA cvs from yesterday, gives these log-messages: Feb 1 17:16:21 fliwatut kernel: hub 1-0:1.0: new USB device on port 1, assigned address 2 Feb 1 17:16:22 fliwatut usb.agent[1429]: ... no modules for USB product 8bb/2902/100 Feb 1 17:16:22 fliwatut usb.agent[1445]: ... no modules for USB product 8bb/2902/100 Feb 1 17:16:22 fliwatut usb.agent[1461]: kernel driver hid already loaded Feb 1 17:16:22 fliwatut kernel: drivers/usb/input/hid-core.c: ctrl urb status -75 received Feb 1 17:16:27 fliwatut kernel: usb 1-1: control timeout on ep0out After that /proc/asound/cards recognizes (?) it like this (card 0 not shown): 1 [default]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-:00:07.2-1 which is a bit strange, because default should be a reserved id, shouldn't it? If I try to play over hw:1 or plughw:1 with aplay, or if I try to open alsamixer on it or if I try to do anything involving the card, the relevant process hangs forever. Even the alsasound init script hangs when it tries to store the mixer settings on reboot, so I have to use the Magic Sysreq keys to actually be able to reboot. Otherwise the machine works fine, I still can use the first soundcard. Below's the usual lsusb -vv output, but to my eyes this looks as if the Edirol device isn't among the displayed settings. Feel free to ask for more debugging info. Any chances to get this to work? lsusb: Bus 002 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.1 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:07.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type none wMaxPacketSize 2 bInterval 255 Language IDs: (length=4) 0409 English(US) Bus 001 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.1 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:07.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type none wMaxPacketSize 2 bInterval 255 Language IDs: (length=4) 0409 English(US) ciao -- Frank Barknecht _ __footils.org__ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse
Re: [Alsa-devel] Remote soundcards.
On Sun, 1 Feb 2004, Filip djMedrzec Zyzniewski wrote: Hello. I have had this idea for some time now, and would like to ask you for your opinions on it. There are several solutions for sound transport. Software like esound, nas, arts etc. All those things have two common problems: 1. They're focused on pcm devices (lacks in mixer support etc) 2. They're not transparent for apps, no common API. 3. They suffer from lags. But we have a nice alsa API, we have support for multiple cards in alsa itself. Now how about developing a patch for alsa-lib, and a small daemon, which together could create a network transparent link, so that local apps (like xmms, mplayer, aumix, mixer_applet, pmidi etc) could use it as an ordinary soundcard? It would: 1. support all devices alsa supports (and their pcms, sequencers and mixers) 2. be usable for any alsa-compatible app 3. not suffer from lags (as a tool for LAN networks, we maybe could get away with soundcard's buffer), it would be usable for applications like Internet telephony (gnomemeeting etc) Who would need this? Linux gets more and more office desktop computers under it's control. Common solution (my company implements these too) are xterminals, dumb boxen with Xserver. There is a need for convenient usage of local devices from main server. for graphics/keyboard/mouse we have XFree86. But no decent solution for sound stuff!. What do you think about it? See alsa-lib/aserver . It not finished yet, but it is good start. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [alsa-cvslog] CVS: alsa-kernel/core rawmidi.c,1.40,1.41
Jaroslav Kysela ha scritto:
Modified Files:
rawmidi.c
Log Message:
copy_*_user() function cannot be called from spinlock context
Index: rawmidi.c
===
RCS file: /cvsroot/alsa/alsa-kernel/core/rawmidi.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- rawmidi.c 23 Oct 2003 14:34:52 - 1.40
+++ rawmidi.c 1 Feb 2004 16:34:28 - 1.41
@@ -909,10 +909,11 @@
if (kernel) {
memcpy(buf + result, runtime-buffer + runtime-appl_ptr,
count1);
} else {
+ spin_unlock_irqrestore(runtime-lock, flags);
if (copy_to_user(buf + result, runtime-buffer +
runtime-appl_ptr, count1)) {
- spin_unlock_irqrestore(runtime-lock, flags);
return result 0 ? result : -EFAULT;
}
+ spin_lock_irqsave(runtime-lock, flags);
}
runtime-appl_ptr += count1;
runtime-appl_ptr %= runtime-buffer_size;
@@ -1133,10 +1134,13 @@
if (kernel) {
memcpy(runtime-buffer + runtime-appl_ptr, buf, count1);
} else {
+ spin_unlock_irqrestore(runtime-lock, flags);
if (copy_from_user(runtime-buffer + runtime-appl_ptr, buf,
count1)) {
+ spin_lock_irqsave(runtime-lock, flags);
result = result 0 ? result : -EFAULT;
goto __end;
}
+ spin_lock_irqsave(runtime-lock, flags);
}
runtime-appl_ptr += count1;
runtime-appl_ptr %= runtime-buffer_size;
With this patch you break write and read atomicity, you should:
1) read and save appl_ptr
2) update appl_ptr and avail
3) leave critical area
4) copy from/to user using saved appl_ptr
5) reenter critical area
I've just checked and a similar mistake has been done too for PCM (and
other places?).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Edirol UA-1X
I am using an Edirol UA-1X with the standard Demudi-kernel (version 2.4.22 with ALSA 0.9.8). While I also see the default id I do not have the problems which you describe. I have also successfully used the UA-1X with SuSE 8.2. I have not yet really tried to use it with a 2.6 kernel and a newer version of ALSA. Cheers, Andreas - Original Message - From: Frank Barknecht [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 01, 2004 5:31 PM Subject: [Alsa-devel] Edirol UA-1X Hallo, here's the second one of my current USB bulk messages: I'm trying to get the Edirol UA-1X to work, which I didn't find in the list of supported devices yet, so maybe this has some interesting information for driver developers. Plugging in the device into a 2.6.1 kernel with ALSA cvs from yesterday, gives these log-messages: Feb 1 17:16:21 fliwatut kernel: hub 1-0:1.0: new USB device on port 1, assigned address 2 Feb 1 17:16:22 fliwatut usb.agent[1429]: ... no modules for USB product 8bb/2902/100 Feb 1 17:16:22 fliwatut usb.agent[1445]: ... no modules for USB product 8bb/2902/100 Feb 1 17:16:22 fliwatut usb.agent[1461]: kernel driver hid already loaded Feb 1 17:16:22 fliwatut kernel: drivers/usb/input/hid-core.c: ctrl urb status -75 received Feb 1 17:16:27 fliwatut kernel: usb 1-1: control timeout on ep0out After that /proc/asound/cards recognizes (?) it like this (card 0 not shown): 1 [default]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-:00:07.2-1 which is a bit strange, because default should be a reserved id, shouldn't it? If I try to play over hw:1 or plughw:1 with aplay, or if I try to open alsamixer on it or if I try to do anything involving the card, the relevant process hangs forever. Even the alsasound init script hangs when it tries to store the mixer settings on reboot, so I have to use the Magic Sysreq keys to actually be able to reboot. Otherwise the machine works fine, I still can use the first soundcard. Below's the usual lsusb -vv output, but to my eyes this looks as if the Edirol device isn't among the displayed settings. Feel free to ask for more debugging info. Any chances to get this to work? lsusb: Bus 002 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.1 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:07.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type none wMaxPacketSize 2 bInterval 255 Language IDs: (length=4) 0409 English(US) Bus 001 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.1 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:07.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7
Re: [Alsa-devel] dmix, dsnoop, asym weirdness [no errors, no sound either]
On Sun, 1 Feb 2004 13:48:38 +0100
Florian Schmidt [EMAIL PROTECTED] wrote:
problem persists with alsa-1.0.2
Flo
Ok, i have a hw mixing capable card, but i do have interest in getting
the dmix/dsnoop/asym thing working. Well, i defined a pasymed device
like this:
--.asoundrc start
#asym fun start here. we define one pcm device called dmixed
pcm.dmixed {
ipc_key 1025
type dmix
slave.pcm hw:0,0
}
#one called dsnooped for capturing
pcm.dsnooped {
ipc_key 1026
type dsnoop
slave.pcm hw:0,0
}
#and this is the real magic
pcm.asymed {
type asym
playback.pcm dmixed
capture.pcm dsnooped
}
#a quick plug plugin for above device to do the converting magic
pcm.pasymed {
type plug
slave.pcm asymed
}
#a ctl device to keep xmms happy
ctl.pasymed {
type hw
card 0
}
--.asoundrc end
Now i should be able to test that device pasymed with the aplay
command:
aplay -D pasymed foo.wav
This command does not give any error messages on my machine. It also
does not produce any sound. The soundfile is rather short and aplay
exits fine after the duration of the soundfile. So i figure it is
played back correctly. The question is though: Where is it played to?
I have three playback devices on my cs46xx soundcard:
[EMAIL PROTECTED]:~$ cat /proc/asound/devices
1: : sequencer
0: [0- 0]: ctl
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
17: [0- 1]: digital audio playback
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
33: : timer
But i have only one speaker pair connected to the soundcard outs. I
just tested the two analoge outs [don't have any digital equipment for
digital out]. The pasymed signal doesn't come out anywhere.. I think
it's a dmix issue, because
aplay -D plug:dmix foo.wav
shows the exact same behaviour [no errors, no sound, normal
termination after duration of soundfile].. dsnoop is behaving weirdly,
too. I just recorded with
arecord -D pasymed -t wav -f cd foo.wav
and it records just a little chunk of audio repeated over and over. It
seems to be the first period that is in the buffer after opening the
device [for i get a file filled with silence when i start recording at
a silent point]. I put up the .wav at
http://mistatapas.ath.cx:/foo.wav
I get the exact same result with
aplay -D plug:dsnooped -t wav -f cd foo.wav
Here's some more info about my setup:
[EMAIL PROTECTED]:~$ uname -a
Linux mango.fruits.de 2.4.22 #1 SMP Wed Nov 19 13:43:03 CET 2003 i686
GNU/Linux
[EMAIL PROTECTED]:~$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.1.
Compiled on Jan 22 2004 for kernel 2.4.22 (SMP) with versioned
symbols.
[EMAIL PROTECTED]:~$ cat /proc/asound/cards
0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
Sound Fusion CS46xx at 0xcffef000/0xcfe0, irq
5
Flo
--
signature :)
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Rawmidi and CONFIG_DEBUG_SPINLOCK_SLEEP
On Sun, 1 Feb 2004, Thomas Charbonnel wrote: The attached patch fixes the problem for me, but I took the obvious and easy way - I may have missed something. Nope. It looks good. I've applied it to CVS. Thanks for analyze. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems with ALSA and SDL
It seems that I'm the only guy who is trying to use an AWE64 without OSS emulation. I've tried asfxload with my AWE64 and it doesn't work. Probably this is due to my ignorance since I've only a basic understanding of PCM playback and none about MIDI (with ALSA I mean). The question is the following : I load all the ALSA modules, both for the sequencer and PCM. In fact the ouput of pmidi -l gives: - Port Client name Port name 64:0 Rawmidi 0 - MPU-401 (UART) 0-0MPU-401 (UART) 0-0 65:0 Emu8000 WaveTable Emu8000 Port 0 65:1 Emu8000 WaveTable Emu8000 Port 1 65:2 Emu8000 WaveTable Emu8000 Port 2 65:3 Emu8000 WaveTable Emu8000 Port 3 66:0 OPL3 FM synth OPL3 FM Port - Then, when I try to load the soundfont with ./asfxload synthgm.sbk I get : No Emux synth hwdep device is found. I've verified with the source code that the problem is at the very beginning when the program call snd_hwdep_open(hwdep, name, 0) I've tried with -D hw:0,2 but the result is the same. I've also verified that a basic sequencer program works but just without playing any sound, of course. I didn't like to bother the devel ML with such kind of problems but there is no documentation about sound font loading without OSS emulation. -- Francesco Abbate --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
