snd-usb-usx2y 0.8.7 hwdep pcm oopses!

snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

Hi,

While testing the new snd-usb-usx2y 0.8.7 hwdep pcm interface on my Tascam
US-224, and feeding it via aplay -D hw:N,2 samefile.wav, I've come to face
a couple of issues I would like to report here.

The first one is about a repeatable kernel crash happening on my SUSE 9.2
Pro box (P4/HT), but also on my Mdk 10.1 laptop (P4/UP), everytime I try
to aplay against the hw:N,2 device (N=soundcard index). See below for the
whole data and the proper oops dumps. As every kernel crash, the system is
left in a very dangerous and unstable state, so that this particular issue
should be addressed ASAP.

OTOH, on the SUSE desktop I've not been able to run jackd with the 'usx2y'
backend driver, always telling me that the 'hwdep' assertion has failed on
hwdep.c:588 (this is from memory). On the laptop, where I've been testing
the usx2y backend quite extensively, it works just fine as myself has
already praised :) Take a note that,o n either box, the snd-usb-usx2y and
kernel versions are exactly the same, so are jackd's, currently
0.99.35cvs, but it doesn't matter as the jack_usx2y backend code is still
Karsten's original. At first glance, the differences I can point between
the two are the hardware (obviously) and the SMP vs. UP kernel. One thing
that now comes to mind is that the snd-usb-usx2y is being loaded as the
third soundcard on the failing system and not as the second as once was
and I'm sure it used to work the last time I've tried long ago.

Here goes the couple of dumps I could grab about the former issue (kernel
oops), taking to note that this was taken from that SUSE/SMP box (but also
occurs on the Mdk/UP laptop).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# uname -a
Linux gamma-suse1 2.6.10-rc2-mm3-RT-V0.7.32-20.0smp #1 SMP Mon Dec 13
20:29:56 WET 2004 i686 i686 i386 GNU/Linux

# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.7 (Thu Nov 11
10:36:46 2004 UTC).

# cat /proc/asound/cards
0 [ICH5           ]: ICH4 - Intel ICH5
                     Intel ICH5 with AD1985 at 0xfebff800, irq 17
1 [CS46xx         ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0xfeafe000/0xfe900000, irq 21
2 [USX2Y          ]: USB US-X2Y - TASCAM US-X2Y
                     TASCAM US-X2Y (1604:8005 if 0 at 001/003)

# cat /proc/asound/hwdep
02-00: /proc/bus/usb/001/003
02-01: /proc/bus/usb/001/003/hwdeppcm

# cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: CS46xx : CS46xx : playback 31 : capture 1
01-01: CS46xx - Rear : CS46xx - Rear : playback 31
01-02: CS46xx - IEC958 : CS46xx - IEC958 : playback 1
01-03: CS46xx - Center LFE : CS46xx - Center LFE : playback 31
02-00: US-X2Y Audio : US-X2Y Audio #0 : playback 1 : capture 1
02-02: US-X2Y hwdep Audio : US-X2Y hwdep Audio : playback 1 : capture 1

> aplay -D hw:2,2 Startup1_1.wav
Playing WAVE 'Startup1_1.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
Segmentation fault

# dmesg
BUG: Unable to handle kernel NULL pointer dereference at virtual address
00000030
 printing eip:
f8c4118a
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in: ohci1394 ieee1394 ehci_hcd usbhid uhci_hcd
intel_mch_agp agpgart evdev wacom snd_pcm_oss snd_mixer_oss snd_seq_midi
snd_seq_midi_event snd_seq snd_usb_usx2y snd_usb_lib snd_hwdep snd_cs46xx
snd_rawmidi snd_seq_device snd_intel8x0 snd_ac97_codec snd_pcm snd_timer
snd soundcore snd_page_alloc realtime commoncap w83781d i2c_sensor i2c_isa
i2c_i801 i2c_core sk98lin subfs dm_mod usbcore
CPU:    0
EIP:    0060:[<f8c4118a>]    Not tainted VLI
EFLAGS: 00010296   (2.6.10-rc2-mm3-RT-V0.7.32-20.0smp)
EIP is at usX2Y_usbpcm_urbs_start+0x14/0x2ac [snd_usb_usx2y]
eax: 00000000   ebx: f65a56a4   ecx: 00000000   edx: f2cf8a40
esi: 00000000   edi: f2f0c614   ebp: f2ebbea8   esp: f2ebbe3c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process aplay (pid: 8078, threadinfo=f2eba000 task=f7790dd0)
Stack: 00000286 f65a5760 00000000 f7790dd0 f8c4149b 00000000 f8c4149b
c01332e2
       f65a56a4 00000000 f2f0c614 f2ebbe7c c010e10c f65a575c f65a5760
f8c414a6
       f8c3f6f0 f65a56a4 00000000 f2f0c614 f2ebbea0 c010e10c 00000000
00000000
Call Trace:
 [<c0103624>] show_stack+0xb4/0xbc (28)
 [<c01037ba>] show_registers+0x169/0x1de (56)
 [<c01039cc>] die+0x10b/0x191 (68)
 [<c01126af>] do_page_fault+0x4d9/0x65a (220)
 [<c0103267>] error_code+0x2b/0x30 (168)
 [<f8c41504>] snd_usX2Y_usbpcm_prepare+0xe2/0x1c1 [snd_usb_usx2y] (44)
 [<f8bcd924>] snd_pcm_do_prepare+0x18/0x36 [snd_pcm] (20)
 [<f8bccd0d>] snd_pcm_action_single+0x33/0x77 [snd_pcm] (28)
 [<f8bccf26>] snd_pcm_action_nonatomic+0x6d/0x83 [snd_pcm] (36)
 [<f8bcd9c9>] snd_pcm_prepare+0x5a/0x6d [snd_pcm] (32)
 [<f8bd004d>] snd_pcm_playback_ioctl1+0x4a/0x309 [snd_pcm] (68)
 [<c017324d>] sys_ioctl+0x172/0x265 (48)
 [<c0102772>] sysenter_past_esp+0x5f/0x85 (-8124)
Code: 60 ff ff ff ff c7 44 24 04 3a 0e c4 f8 89 14 24 e8 82 e4 ff ff c9 c3
55 89 e5 57 56 53 83 ec 60 e8 74 cf 4c c7 8b 55 08 8b 42 04 <8b> 40 30 89
45 a4 83 f8 01 8b 0a 89 4d a0 0f 84 26 02 00 00 83

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# uname -a
Linux gamma-suse1 2.6.8-24.5-smp #5 SMP Mon Dec 13 22:56:42 WET 2004 i686
i686 i386 GNU/Linux

# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.7rc1.
Compiled on Nov 30 2004 for kernel 2.6.8-24.5-smp (SMP).

# cat /proc/asound/cards
0 [ICH5           ]: ICH4 - Intel ICH5
                     Intel ICH5 with AD1985 at 0xfebff800, irq 201
1 [CS46xx         ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0xfeafe000/0xfe900000, irq 225
2 [USX2Y          ]: USB US-X2Y - TASCAM US-X2Y
                     TASCAM US-X2Y (1604:8005 if 0 at 002/003)

# cat /proc/asound/hwdep
02-00: /proc/bus/usb/002/003
02-01: /proc/bus/usb/002/003/hwdeppcm

# cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: CS46xx : CS46xx : playback 31 : capture 1
01-01: CS46xx - Rear : CS46xx - Rear : playback 31
01-02: CS46xx - IEC958 : CS46xx - IEC958 : playback 1
01-03: CS46xx - Center LFE : CS46xx - Center LFE : playback 31
02-00: US-X2Y Audio : US-X2Y Audio #0 : playback 1 : capture 1
02-02: US-X2Y hwdep Audio : US-X2Y hwdep Audio : playback 1 : capture 1

> aplay -D hw:2,2 Startup1_1.wav
Playing WAVE 'Startup1_1.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
Segmentation fault

# dmesg
Unable to handle kernel NULL pointer dereference at virtual address 00000030
 printing eip:
f9b330f0
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: appletalk ax25 ipx nvram wacom snd_pcm_oss
snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq snd_usb_usx2y
snd_usb_lib snd_hwdep edd snd_cs46xx snd_rawmidi snd_seq_device gameport
ipv6 snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore
snd_page_alloc realtime w83781d i2c_sensor i2c_isa i2c_i801 i2c_core
usbhid joydev sg st sd_mod sr_mod scsi_mod ide_cd cdrom subfs ohci1394
ieee1394 hw_random uhci_hcd ehci_hcd intel_agp agpgart evdev sk98lin
dm_mod usbcore reiserfs
CPU:    0
EIP:    0060:[<f9b330f0>]    Tainted:  G  U VLI
EFLAGS: 00010292   (2.6.8-24.5-smp )
EIP is at usX2Y_usbpcm_urbs_start+0x10/0x300 [snd_usb_usx2y]
eax: 00000000   ebx: 00000000   ecx: cdfff680   edx: f6564714
esi: f6e4aa28   edi: f20ec614   ebp: f6564714   esp: f2745e58
ds: 007b   es: 007b   ss: 0068
Process aplay (pid: 6258, threadinfo=f2744000 task=f78081b0)
Stack: 00000282 00000021 cdfaa494 f2bb1280 f9b31e97 000003d9 f9b37060
cdfaa794
       00000000 f6564714 00000000 f78081b0 c0121650 f2745eac f2745eac
00000015
       000000d0 00000001 00000000 f78081b0 c0121650 f2745eac f2745eac
00000004
Call Trace:
 [<f9b31e97>] usX2Y_rate_set+0x157/0x240 [snd_usb_usx2y]
 [<c0121650>] autoremove_wake_function+0x0/0x50
 [<c0121650>] autoremove_wake_function+0x0/0x50
 [<f99d820f>] snd_malloc_pages+0x4f/0xa0 [snd_page_alloc]
 [<f9b334aa>] snd_usX2Y_usbpcm_prepare+0xca/0x250 [snd_usb_usx2y]
 [<f9a50fc9>] snd_pcm_do_prepare+0x9/0x20 [snd_pcm]
 [<f9a5047b>] snd_pcm_action_single+0x2b/0x90 [snd_pcm]
 [<f9a5069e>] snd_pcm_action_nonatomic+0x5e/0x60 [snd_pcm]
 [<f9a5105a>] snd_pcm_prepare+0x4a/0x70 [snd_pcm]
 [<f9a53abf>] snd_pcm_playback_ioctl1+0x5f/0x360 [snd_pcm]
 [<c011e83d>] finish_task_switch+0x3d/0x90
 [<c03464f2>] schedule+0x382/0xb90
 [<c0252720>] write_chan+0x0/0x240
 [<f9a54122>] snd_pcm_playback_ioctl+0x52/0x90 [snd_pcm]
 [<c0174de1>] sys_ioctl+0x211/0x2d0
 [<c0107029>] sysenter_past_esp+0x52/0x79
Code: 00 00 00 8b 40 20 c7 40 48 ff ff ff ff ba c0 2d b3 f9 89 c8 e9 b2 e5
ff ff 89 f6 55 89 c2 57 56 53 83 ec 68 89 44 24 24 8b 40 04 <8b> 40 30 89
44 24 18 8b 0a 48 89 4c 24 14 0f 84 60 02 00 00 83

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Should I add this to the alsa-driver mantis bugtracker? =:)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Karsten Wiese]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

Am Dienstag 14 Dezember 2004 10:47 schrieb Rui Nuno Capela:
> Hi,
> 
> While testing the new snd-usb-usx2y 0.8.7 hwdep pcm interface on my Tascam
> US-224, and feeding it via aplay -D hw:N,2 samefile.wav, I've come to face
> a couple of issues I would like to report here.
> 
> The first one is about a repeatable kernel crash happening on my SUSE 9.2
> Pro box (P4/HT), but also on my Mdk 10.1 laptop (P4/UP), everytime I try
> to aplay against the hw:N,2 device (N=soundcard index). See below for the
> whole data and the proper oops dumps. As every kernel crash, the system is
> left in a very dangerous and unstable state, so that this particular issue
> should be addressed ASAP.

OK, that one is fixed by attached patch.
Takashi: Please apply with
>>>>>>
Summary: return -EBUSY from snd_usX2Y_usbpcm_open(),
  if the associated hwdep device is not opened.

It now works as originally intended. Had forgotten a pair of parenthesis.

Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
<<<<<<
 

> OTOH, on the SUSE desktop I've not been able to run jackd with the 'usx2y'
> backend driver, always telling me that the 'hwdep' assertion has failed on
> hwdep.c:588 (this is from memory). On the laptop, where I've been testing
> the usx2y backend quite extensively, it works just fine as myself has
> already praised :) Take a note that,o n either box, the snd-usb-usx2y and
> kernel versions are exactly the same, so are jackd's, currently
> 0.99.35cvs, but it doesn't matter as the jack_usx2y backend code is still
> Karsten's original. At first glance, the differences I can point between
> the two are the hardware (obviously) and the SMP vs. UP kernel. One thing
> that now comes to mind is that the snd-usb-usx2y is being loaded as the
> third soundcard on the failing system and not as the second as once was
> and I'm sure it used to work the last time I've tried long ago.

Could be that assert: 
const char *snd_hwdep_dsp_status_get_id(const snd_hwdep_dsp_status_t *obj)
{
 assert(obj);
 return obj->id;
}

Mmmh,,,,,, what could cause it ?
Rui: Just 1 idea: Does this also happen, when jackd is started as root?
I had udev assigning some devices rights to root only occasionally.

Karsten

[-- Attachment #2: snd-usb-usx2y.patch.0.8.7.1 --]
[-- Type: text/x-diff, Size: 2234 bytes --]

Index: alsa-kernel/usb/usx2y/usbusx2y.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usx2y/usbusx2y.c,v
retrieving revision 1.7
diff -U3 -r1.7 usbusx2y.c
--- alsa-kernel/usb/usx2y/usbusx2y.c	2 Dec 2004 14:41:21 -0000	1.7
+++ alsa-kernel/usb/usx2y/usbusx2y.c	14 Dec 2004 18:26:02 -0000
@@ -1,6 +1,10 @@
 /*
  * usbusy2y.c - ALSA USB US-428 Driver
  *
+2004-12-14 Karsten Wiese
+	Version 0.8.7.1:
+	snd_pcm_open for rawusb pcm-devices now returns -EBUSY if called without rawusb's hwdep device being open.
+
 2004-12-02 Karsten Wiese
 	Version 0.8.7:
 	Use macro usb_maxpacket() for portability.
@@ -139,7 +143,7 @@
 
 
 MODULE_AUTHOR("Karsten Wiese <annabellesgarden@yahoo.de>");
-MODULE_DESCRIPTION("TASCAM "NAME_ALLCAPS" Version 0.8.7");
+MODULE_DESCRIPTION("TASCAM "NAME_ALLCAPS" Version 0.8.7.1");
 MODULE_LICENSE("GPL");
 MODULE_SUPPORTED_DEVICE("{{TASCAM(0x1604), "NAME_ALLCAPS"(0x8001)(0x8005)(0x8007) }}");
 
Index: alsa-kernel/usb/usx2y/usx2yhwdeppcm.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usx2y/usx2yhwdeppcm.c,v
retrieving revision 1.1
diff -U3 -r1.1 usx2yhwdeppcm.c
--- alsa-kernel/usb/usx2y/usx2yhwdeppcm.c	8 Dec 2004 19:29:21 -0000	1.1
+++ alsa-kernel/usb/usx2y/usx2yhwdeppcm.c	14 Dec 2004 18:26:04 -0000
@@ -22,7 +22,7 @@
  It provides the alsa kernel half of the usx2y-alsa-jack driver pair.
  The pair uses a hardware dependant alsa-device for mmaped pcm transport.
  Advantage achieved:
-         The usb_hcd places reads/writes pcm data into dma-memory.
+         The usb_hc moves pcm data from/into memory via DMA.
          That memory is mmaped by jack's usx2y driver.
          Jack's usx2y driver is the first/last to read/write pcm data.
          Read/write is a combination of power of 2 period shaping and
@@ -568,7 +568,7 @@
 					 snd_pcm_substream_chip(substream))[substream->stream];
 	snd_pcm_runtime_t	*runtime = substream->runtime;
 
-	if (!subs->usX2Y->chip_status & USX2Y_STAT_CHIP_MMAP_PCM_URBS)
+	if (!(subs->usX2Y->chip_status & USX2Y_STAT_CHIP_MMAP_PCM_URBS))
 		return -EBUSY;
 
 	runtime->hw = SNDRV_PCM_STREAM_PLAYBACK == substream->stream ? snd_usX2Y_2c :

Re: Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

Karsten Wiese wrote:
> Rui Nuno Capela wrote:
>
>> OTOH, on the SUSE desktop I've not been able to run jackd with the
>> 'usx2y' backend driver, always telling me that the 'hwdep' assertion
>> has failed on hwdep.c:588 (this is from memory). On the laptop, where
>> I've been testing the usx2y backend quite extensively, it works just
>> fine as myself has already praised :) Take a note that,o n either box,
>> the snd-usb-usx2y and kernel versions are exactly the same, so are
>> jackd's, currently 0.99.35cvs, but it doesn't matter as the jack_usx2y
>> backend code is still Karsten's original. At first glance, the
>> differences I can point between the two are the hardware (obviously)
>> and the SMP vs. UP kernel. One> thing that now comes to mind is that
>> the snd-usb-usx2y is being loaded as the third soundcard on the failing
>> system and not as the second as once was and I'm sure it used to work
>> the last time I've tried long ago.
>

BINGO! Just did a quick test, by removing the 2nd card (snd-cs46xx) from
modprobe.conf and renumbering snd-usb-usx2y back to index=1, just like
this:

 alias snd-card-1 snd-usb-usx2y
 alias sound-slot-1 snd-usb-usx2y
 options snd-usb-usx2y index=1 enable=1 nrpacks=1

and now I can start 'jackd -R -dusx2y -d:hw:1,2 ...' without the slightest
complaint. The /proc/asound info looks like this:

# cat /proc/asound/cards
0 [ICH5           ]: ICH4 - Intel ICH5
                     Intel ICH5 with AD1985 at 0xfebff800, irq 17
1 [USX2Y          ]: USB US-X2Y - TASCAM US-X2Y
                     TASCAM US-X2Y (1604:8005 if 0 at 001/003)

# cat /proc/asound/hwdep
01-00: /proc/bus/usb/001/003
01-01: /proc/bus/usb/001/003/hwdeppcm

# cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: US-X2Y Audio : US-X2Y Audio #0 : playback 1 : capture 1
01-02: US-X2Y hwdep Audio : US-X2Y hwdep Audio : playback 1 : capture 1


Again, If I put back snd-usb-usx2y as index=2,

 alias snd-card-2 snd-usb-usx2y
 alias sound-slot-2 snd-usb-usx2y
 options snd-usb-usx2y index=2 enable=1 nrpacks=1

after alsasound restart, the /proc/asound info becomes:

# cat /proc/asound/cards
0 [ICH5           ]: ICH4 - Intel ICH5
                     Intel ICH5 with AD1985 at 0xfebff800, irq 17
1 [CS46xx         ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0xfeafe000/0xfe900000, irq 21
2 [USX2Y          ]: USB US-X2Y - TASCAM US-X2Y
                     TASCAM US-X2Y (1604:8005 if 0 at 001/005)

# cat /proc/asound/hwdep
02-00: /proc/bus/usb/001/005
02-01: /proc/bus/usb/001/005/hwdeppcm

# cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: CS46xx : CS46xx : playback 31 : capture 1
01-01: CS46xx - Rear : CS46xx - Rear : playback 31
01-02: CS46xx - IEC958 : CS46xx - IEC958 : playback 1
01-03: CS46xx - Center LFE : CS46xx - Center LFE : playback 31
02-00: US-X2Y Audio : US-X2Y Audio #0 : playback 1 : capture 1
02-02: US-X2Y hwdep Audio : US-X2Y hwdep Audio : playback 1 : capture 1

And, starting 'jackd -R -dusx2y -dhw:2,2 ...' ends abnormally, with the
error line:

jackd: hwdep.c:263: snd_hwdep_poll_descriptors: Assertion `hwdep' failed.

>
> Could be that assert:
> const char *snd_hwdep_dsp_status_get_id(const snd_hwdep_dsp_status_t *obj)
> {
>  assert(obj);
>  return obj->id;
> }
>
> Mmmh,,,,,, what could cause it ?
> Rui: Just 1 idea: Does this also happen, when jackd is started as root?
> I had udev assigning some devices rights to root only occasionally.
>

Nope. Staring as root gives exactly the same result.

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

Hi Karsten,
>>
>> The first one is about a repeatable kernel crash happening on my SUSE
>> 9.2 Pro box (P4/HT), but also on my Mdk 10.1 laptop (P4/UP), everytime
>> I try to aplay against the hw:N,2 device (N=soundcard index). See below
>> for the whole data and the proper oops dumps. As every kernel crash,
>> the system is left in a very dangerous and unstable state, so that this
>> particular issue should be addressed ASAP.
>
> OK, that one is fixed by attached patch.
> Takashi: Please apply with
>>>>>>>
> Summary: return -EBUSY from snd_usX2Y_usbpcm_open(),
>   if the associated hwdep device is not opened.
>
> It now works as originally intended. Had forgotten a pair of parenthesis.
>
> Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
> <<<<<<
>

With this patch applied, I always get:

ALSA lib pcm_hw.c:1172:(snd_pcm_hw_open) open /dev/snd/pcmC2D2p failed:
Device or resource busy

either from jackd or aplay on hw:2,2. It doesn't matter whether
snd-usb-usx2y is loaded on index=1 or index=2. The resulty is *always*
resource busy.

Guess the patch doesn't really help, eh? I does not crash however ;)
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Karsten Wiese]

Am Mittwoch 15 Dezember 2004 01:17 schrieb Rui Nuno Capela:
> Hi Karsten,
> >>
> >> The first one is about a repeatable kernel crash happening on my SUSE
> >> 9.2 Pro box (P4/HT), but also on my Mdk 10.1 laptop (P4/UP), everytime
> >> I try to aplay against the hw:N,2 device (N=soundcard index). See below
> >> for the whole data and the proper oops dumps. As every kernel crash,
> >> the system is left in a very dangerous and unstable state, so that this
> >> particular issue should be addressed ASAP.
> >
> > OK, that one is fixed by attached patch.
> > Takashi: Please apply with
> >>>>>>>
> > Summary: return -EBUSY from snd_usX2Y_usbpcm_open(),
> >   if the associated hwdep device is not opened.
> >
> > It now works as originally intended. Had forgotten a pair of parenthesis.
> >
> > Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
> > <<<<<<
> >
> 
> With this patch applied, I always get:
> 
> ALSA lib pcm_hw.c:1172:(snd_pcm_hw_open) open /dev/snd/pcmC2D2p failed:
> Device or resource busy
> 
> either from jackd or aplay on hw:2,2. It doesn't matter whether
> snd-usb-usx2y is loaded on index=1 or index=2. The resulty is *always*
> resource busy.
> 
> Guess the patch doesn't really help, eh? I does not crash however ;)

Thats "correct behaviour":
usx2y-wise hw:n,2 is only valid for "rawusb pcm". aplay talks "standard pcm", so it cannot use hw:n,2 but only hw:n (or hw:n,0).
Technically,  snd_pcm_open() called for usx2y's hw:n,2 device will only succeed, if the hwdep device n,1 is opened already.
Also then (hwdep device n,1 opened) snd_pcm_open() calls for usx2y's hw:n,0 (or hw:n) will return -EBUSY.
In short:
hw:n is for "standard alsa pcm"
hw:n,2 is for "rawusb pcm" (currently only usable with jackd's usx2y driver)
Does hw:n (without the ",2") work with aplay and jackd -d alsa?

cheers,
Karsten


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

Karsten,

>> >>>>>>>
>> > Summary: return -EBUSY from snd_usX2Y_usbpcm_open(),
>> >   if the associated hwdep device is not opened.
>> >
>> > It now works as originally intended. Had forgotten a pair of
>> parenthesis.
>> >
>> > Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
>> > <<<<<<
>> >
>>
>> With this patch applied, I always get:
>>
>> ALSA lib pcm_hw.c:1172:(snd_pcm_hw_open) open /dev/snd/pcmC2D2p failed:
>> Device or resource busy
>>
>> either from jackd or aplay on hw:2,2. It doesn't matter whether
>> snd-usb-usx2y is loaded on index=1 or index=2. The resulty is *always*
>> resource busy.
>>
>
> Thats "correct behaviour":
> usx2y-wise hw:n,2 is only valid for "rawusb pcm". aplay talks "standard
> pcm", so it cannot use hw:n,2 but only hw:n (or hw:n,0).
> Technically,  snd_pcm_open() called for usx2y's hw:n,2 device will only
> succeed, if the hwdep device n,1 is opened already.
> Also then (hwdep device n,1 opened) snd_pcm_open() calls for usx2y's
> hw:n,0 (or hw:n) will return -EBUSY.
> In short:
> hw:n is for "standard alsa pcm"
> hw:n,2 is for "rawusb pcm" (currently only usable with jackd's usx2y
> driver)
> Does hw:n (without the ",2") work with aplay and jackd -d alsa?
>

Yes,

  jackd -d alsa -d hw:n ... works OK,

but

  jackd -d usx2y -d hw:n,2 ... returns a 'resource busy' condition.

Without the 0.8.7.1 patch, it works BUT iif n < 2; if n >= 2, I get the
'hwdep' assertion failure on jackd; aplay crashes on either value of n.

With the patch applied, I always get the "resource busy" error on 'jackd
-d usx2y -d hw:n,2 ...' and on 'aplay -D hw:n,2 ...'.

So, the sacred question is: How can I make jackd to work with the "rawusb"
interface?

Just a clueless question: does it need a newer version for the jackd usx2y
backend driver? I'm still using your's original one you've ever posted.
I've been maintaining it as a jack patch and can be found on my personal
home server (http://www.rncbc.org/usx2y/jack-0.99.35-usx2y.patch.gz).

Please, have a look and check if it still fits in.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

Hi Karsten,

>   jackd -d usx2y -d hw:n,2 ... returns a 'resource busy' condition.
>
> Without the 0.8.7.1 patch, it works BUT iif n < 2; if n >= 2, I get the
> 'hwdep' assertion failure on jackd; aplay crashes on either value of n.
>
> With the patch applied, I always get the "resource busy" error on 'jackd
> -d usx2y -d hw:n,2 ...' and on 'aplay -D hw:n,2 ...'.
>
> So, the sacred question is: How can I make jackd to work with the "rawusb"
> interface?
>
> Just a clueless question: does it need a newer version for the jackd usx2y
> backend driver? I'm still using your's original one you've ever posted.
> I've been maintaining it as a jack patch and can be found on my personal
> home server (http://www.rncbc.org/usx2y/jack-0.99.35-usx2y.patch.gz).
>

I found the culprid, almost for sure.

On jack/drivers/usx2y/usx2y_driver.c:2158, you may find there's this
hardcoded:

    snd_hwdep_open(&driver->hwdep_handle, "hw:1,1", O_RDWR);
                                           ^^^^^^

so I guess this could only work if snd-usb-usx2y is your second soundcard
(index=1). Indeed it was on all my successful tests. That explains a lot
of trouble.

Simple dummy question: how can I avoid that hardwiring, and fill in the
proper soundcard index number n, as in "hw:n,1" ? In other words, how can
I retrieve that number, given the alsa device name (e.g. str="hw:2,2")
without going dirty as in sscanf(str, "hw:%d", &n); ?

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Takashi Iwai]

At Wed, 15 Dec 2004 14:05:05 -0000 (WET),
Rui Nuno Capela wrote:
> 
> Hi Karsten,
> 
> >   jackd -d usx2y -d hw:n,2 ... returns a 'resource busy' condition.
> >
> > Without the 0.8.7.1 patch, it works BUT iif n < 2; if n >= 2, I get the
> > 'hwdep' assertion failure on jackd; aplay crashes on either value of n.
> >
> > With the patch applied, I always get the "resource busy" error on 'jackd
> > -d usx2y -d hw:n,2 ...' and on 'aplay -D hw:n,2 ...'.
> >
> > So, the sacred question is: How can I make jackd to work with the "rawusb"
> > interface?
> >
> > Just a clueless question: does it need a newer version for the jackd usx2y
> > backend driver? I'm still using your's original one you've ever posted.
> > I've been maintaining it as a jack patch and can be found on my personal
> > home server (http://www.rncbc.org/usx2y/jack-0.99.35-usx2y.patch.gz).
> >
> 
> I found the culprid, almost for sure.
> 
> On jack/drivers/usx2y/usx2y_driver.c:2158, you may find there's this
> hardcoded:
> 
>     snd_hwdep_open(&driver->hwdep_handle, "hw:1,1", O_RDWR);
>                                            ^^^^^^
> 
> so I guess this could only work if snd-usb-usx2y is your second soundcard
> (index=1). Indeed it was on all my successful tests. That explains a lot
> of trouble.
> 
> Simple dummy question: how can I avoid that hardwiring, and fill in the
> proper soundcard index number n, as in "hw:n,1" ? In other words, how can
> I retrieve that number, given the alsa device name (e.g. str="hw:2,2")
> without going dirty as in sscanf(str, "hw:%d", &n); ?

You can get the card number from ctl or pcm instance.
Check snd_*_get_card() functions.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Karsten Wiese]

Am Mittwoch 15 Dezember 2004 15:12 schrieb Takashi Iwai:
> At Wed, 15 Dec 2004 14:05:05 -0000 (WET),
> Rui Nuno Capela wrote:
> > 
> > Hi Karsten,
> > 
> > >   jackd -d usx2y -d hw:n,2 ... returns a 'resource busy' condition.
> > >
> > > Without the 0.8.7.1 patch, it works BUT iif n < 2; if n >= 2, I get the
> > > 'hwdep' assertion failure on jackd; aplay crashes on either value of n.
> > >
> > > With the patch applied, I always get the "resource busy" error on 'jackd
> > > -d usx2y -d hw:n,2 ...' and on 'aplay -D hw:n,2 ...'.
> > >
> > > So, the sacred question is: How can I make jackd to work with the "rawusb"
> > > interface?
> > >
> > > Just a clueless question: does it need a newer version for the jackd usx2y
> > > backend driver? I'm still using your's original one you've ever posted.
> > > I've been maintaining it as a jack patch and can be found on my personal
> > > home server (http://www.rncbc.org/usx2y/jack-0.99.35-usx2y.patch.gz).
> > >
> > 
> > I found the culprid, almost for sure.
> > 
> > On jack/drivers/usx2y/usx2y_driver.c:2158, you may find there's this
> > hardcoded:
> > 
> >     snd_hwdep_open(&driver->hwdep_handle, "hw:1,1", O_RDWR);
> >                                            ^^^^^^
( me flushing )  erm, really forgot about that one. Cool that you found it!
> > 
> > so I guess this could only work if snd-usb-usx2y is your second soundcard
> > (index=1). Indeed it was on all my successful tests. That explains a lot
> > of trouble.
> > 
> > Simple dummy question: how can I avoid that hardwiring, and fill in the
> > proper soundcard index number n, as in "hw:n,1" ? In other words, how can
> > I retrieve that number, given the alsa device name (e.g. str="hw:2,2")
> > without going dirty as in sscanf(str, "hw:%d", &n); ?
> 
> You can get the card number from ctl or pcm instance.
> Check snd_*_get_card() functions.
> 
We haven't any of those yet, as hwdep device is the first one to be opened.
So we could change jackd's usx2y driver's parameters a little:
 $ jackd -dusx2y -c1
or
 $ jackd -dusx2y --card 1
in the jackd usx2y driver we would sprintf the real alsa devicenames like this:
char hwdep_devicename[8];
char pcm_devicename[8];
int card; //holds card nr parameter

sprintf(hwdep_devicename, "hw:%i,1", card);
sprintf(pcm_devicename, "hw:%i,2", card);

thus we'd hide away the complications from the commandline.

Ok?






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Takashi Iwai]

At Wed, 15 Dec 2004 15:32:34 +0100,
Karsten Wiese wrote:
> 
> > You can get the card number from ctl or pcm instance.
> > Check snd_*_get_card() functions.
> > 
> We haven't any of those yet, as hwdep device is the first one to be opened.

hwdep has also one - snd_hwdep_info_get_card().

> So we could change jackd's usx2y driver's parameters a little:
>  $ jackd -dusx2y -c1
> or
>  $ jackd -dusx2y --card 1
> in the jackd usx2y driver we would sprintf the real alsa devicenames like this:
> char hwdep_devicename[8];
> char pcm_devicename[8];
> int card; //holds card nr parameter
> 
> sprintf(hwdep_devicename, "hw:%i,1", card);
> sprintf(pcm_devicename, "hw:%i,2", card);
> 
> thus we'd hide away the complications from the commandline.

Yes, this looks much easier (also good for future changes of hwdep/pcm
assignment).


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Karsten Wiese]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Hi Rui

Am Mittwoch 15 Dezember 2004 15:38 schrieb Takashi Iwai:
> At Wed, 15 Dec 2004 15:32:34 +0100,
> Karsten Wiese wrote:
> > 
> > > You can get the card number from ctl or pcm instance.
> > > Check snd_*_get_card() functions.
> > > 
> > We haven't any of those yet, as hwdep device is the first one to be opened.
> 
> hwdep has also one - snd_hwdep_info_get_card().
> 
> > So we could change jackd's usx2y driver's parameters a little:
> >  $ jackd -dusx2y -c1
> > or
> >  $ jackd -dusx2y --card 1
> > in the jackd usx2y driver we would sprintf the real alsa devicenames like this:
> > char hwdep_devicename[8];
> > char pcm_devicename[8];
> > int card; //holds card nr parameter
> > 
> > sprintf(hwdep_devicename, "hw:%i,1", card);
> > sprintf(pcm_devicename, "hw:%i,2", card);
> > 
> > thus we'd hide away the complications from the commandline.
> 
> Yes, this looks much easier (also good for future changes of hwdep/pcm
> assignment).

with attached snapshot of my jack/drivers/usx2y things work here like proposed:
you only need to
 $ jackd -dusx2y
and stuff starts if you have such a beast up & running.
 $ jackd -dusx2y -cn 
with n from 0 to 7 also works, if n is usx2y.
But -cn is only needed if you have more than 1 usx2y.
(I doubt any of us linuxers has)
Of course our beloved
 $ jackd -R -dusx2y -n2 -p128 
is still ticking.

Please verify. And if succesfull, set up real patches & publish.

Thanks,
Karsten

[-- Attachment #2: jack-usx2y-driver_041215.tar.gzip --]
[-- Type: application/x-gzip, Size: 18764 bytes --]

Re: snd-usb-usx2y 0.8.7 hwdep pcm oopses!

[Rui Nuno Capela]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

Karsten,

I've took the dirty path, so to speak, and this attached patch/fix is what
I just come along--it's now working with snd-usb-usx2y 0.8.7.1. It avoids
the new usx2y backend driver argument -c as you suggested, by deriving the
soundcard index from the given playback device name (default is 0). I
think it works for the most usual cases.

BTW, one can be also derive the pcm_name (as "hw:%d,2"), so there will be
no need to give it explicitly on the jackd command line, you just give
hw:n instead of hw:n,2 (which looks too magic to my taste :)

Now,... some notes for your thoughts: IMO, and I think we must keep that
in clear mind, is that (y)our new experimental usx2y_driver.c will be only
accepted, officially and made into the JACK tree, if and only if we can
manage to merge it into the current jack/drivers/alsa/alsa_driver.c.

I might start working on that tentative merge ASAP. My will is that next
time I propose this usx2y stuff to be included on the jack cvs tree, it
will be under the form of a alsa_driver patch, not a cloned one (as it is
right now). I hope I(we) get it in time for the next jack release ;)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


diff -up jack.0/drivers/usx2y/usx2y_driver.c
jack.1/drivers/usx2y/usx2y_driver.c
--- jack.0/drivers/usx2y/usx2y_driver.c	2004-12-13 21:34:13.000000000 +0000
+++ jack.1/drivers/usx2y/usx2y_driver.c	2004-12-15 22:01:57.000000000 +0000
@@ -2087,6 +2087,10 @@ usx2y_driver_new (char *name, char *play

 	usx2y_driver_t *driver;

+	char *hwdep_colon;
+	int   hwdep_card;
+	char  hwdep_name[9];
+
 	printf ("experimental alsa driver ... %s|%s|%" PRIu32 "|%" PRIu32
 		"|%" PRIu32"|%" PRIu32"|%" PRIu32 "|%s|%s|%s|%s\n",
 		playing ? playback_usx2y_device : "-",
@@ -2155,7 +2159,11 @@ usx2y_driver_new (char *name, char *play
 	driver->xrun_count = 0;
 	driver->process_count = 0;

-	snd_hwdep_open(&driver->hwdep_handle, "hw:1,1", O_RDWR);
+	hwdep_card = 0;
+	if ((hwdep_colon = strrchr(playback_usx2y_device, ':')) != NULL)
+		sscanf(hwdep_colon, ":%d", &hwdep_card);
+	snprintf(hwdep_name, sizeof(hwdep_name) - 1, "hw:%d,1", hwdep_card);
+	snd_hwdep_open(&driver->hwdep_handle, hwdep_name, O_RDWR);

 	if (playing) {
 		if (snd_pcm_open (&driver->playback_handle,


[-- Attachment #2: jack-0.99.35-usx2y-fix.patch.gz --]
[-- Type: application/x-gzip, Size: 514 bytes --]

[JACK-PATCH] Tascam US-X2Y hwdep pcm (aka rawusb) backend driver

[Rui Nuno Capela]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Hi,

Just in time for Xmas! here goes my initial proposal to merge the once
outsider USX2Y driver into the mainstrem JACK's ALSA backend. This is
specific to all you Tascam US-122/224/428 owners, and thanks goes most to
Karsten Wiese for the original experimental code.

I strongly hope this is now ready for official approval, as the changes to
alsa_driver.{h,c} code are rather minimal and almost innocuous. All new
stuff is really introduced on the usx2y.{h,c} files. Check it out.

So, for you to use this thingie, you just plug your US-x2y as ever before,
for example:

    jackd -dalsa -dhw:1 -r44100 -p1024 -n2 -S

will make use of the default alsa backend code path *exactly* as it is. No
overhead but no low-latency joy either ;)

However, you better rejoice if you've snd-usb-usx2y >= 0.8.7 already on
your kernel; you can take advantage from the so-called "rawusb" mode, by
using its new hwdep pcm interface:

    jackd -dalsa -dhw:1,2 -r44100 -p64 -n2 -S

Note that you *must* specify hw:n,2 in the device name (n=soundcard index)
for the new alsa/usx2y backend driver take control and override the
generic default one.

Ah, and -p64 is no typo at all ;)

Attached patch applies to current jack-0.99.37 CVS HEAD.

Happy holiday.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


[-- Attachment #2: jack-0.99.37-alsa-usx2y-9.patch.gz --]
[-- Type: application/x-gzip-compressed, Size: 7766 bytes --]