[alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering, alsamixer even segfaults when I reach the end of the controls listed. Plain weird. Smells like something changed deep in the kernel that makes alsa-lib very unhappy. Alsa-tools rebuilt from source does not make a difference.
Weirdness goes away when I boot into 2.6.29.6 rt23...
Is there anything in alsa-* that depends on which _kernel_ is available at compile time?
-- Fernando
On Tue, 2010-02-16 at 17:58 -0800, Fernando Lopez-Lezcano wrote:
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering,
This is what hdspmixer prints when I attempt to run it:
---- $ hdspmixer
HDSPMixer 1.6 - Copyright (C) 2003 Thomas Charbonnel thomas@undata.org This program comes with ABSOLUTELY NO WARRANTY HDSPMixer is free software, see the file COPYING for details
Looking for HDSP cards : Card 0 : HDA Intel at 0xfe020000 irq 17 Card 1 : RME Hammerfall DSP + Multiface at 0xc0000000, irq 16 Multiface found ! 1 Hammerfall DSP card found. Initializing default presets HwDep ioctl failed. Metering stopped ----
alsamixer even segfaults when I reach the end of the controls listed. Plain weird. Smells like something changed deep in the kernel that makes alsa-lib very unhappy. Alsa-tools rebuilt from source does not make a difference.
Weirdness goes away when I boot into 2.6.29.6 rt23...
Is there anything in alsa-* that depends on which _kernel_ is available at compile time?
I have been trying to see if I can figure _anything_ out of this...
A diff of 2.6.29 (last known working) against 2.6.31.12 reveals something that might have an influence on the problem:
in snd_hdsp_create_hwdep there are two lines added:
+ hw->ops.open = snd_hdsp_hwdep_dummy_op; hw->ops.ioctl = snd_hdsp_hwdep_ioctl; + hw->ops.release = snd_hdsp_hwdep_dummy_op;
And snd_hdsp_hwdep_dummy_op just returns 0...
Other differences between the two files (not that many) seem irrelevant to me.
I imagine this is what is causing the difference in behavior (hwdep fails). Any suggestions on what I could try to fix this?
Thanks for any help!
-- Fernando
On Mon, 2010-02-22 at 23:51 +0000, Fernando Lopez-Lezcano wrote:
On Tue, 2010-02-16 at 17:58 -0800, Fernando Lopez-Lezcano wrote:
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering,
This is what hdspmixer prints when I attempt to run it:
$ hdspmixer
HDSPMixer 1.6 - Copyright (C) 2003 Thomas Charbonnel thomas@undata.org This program comes with ABSOLUTELY NO WARRANTY HDSPMixer is free software, see the file COPYING for details
Looking for HDSP cards : Card 0 : HDA Intel at 0xfe020000 irq 17 Card 1 : RME Hammerfall DSP + Multiface at 0xc0000000, irq 16 Multiface found ! 1 Hammerfall DSP card found. Initializing default presets HwDep ioctl failed. Metering stopped
And this is what strace says:
---- open("/dev/snd/controlC1", O_RDONLY|O_CLOEXEC) = 5 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 ioctl(5, UI_DEV_CREATE, 0xbff6aef4) = 0 close(5) = 0 open("/dev/snd/hwC1D0", O_RDONLY|O_CLOEXEC) = 5 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 ioctl(5, 0x80044800, 0xbff6b270) = 0 ioctl(5, SNDRV_HDSP_IOCTL_GET_PEAK_RMS, 0xbff6b57c) = -1 EINVAL (Invalid argument) write(2, "HwDep ioctl failed. Metering sto"..., 37HwDep ioctl failed. Metering stopped ) = 37 close(5) = 0 ----
-- Fernando
alsamixer even segfaults when I reach the end of the controls listed. Plain weird. Smells like something changed deep in the kernel that makes alsa-lib very unhappy. Alsa-tools rebuilt from source does not make a difference.
Weirdness goes away when I boot into 2.6.29.6 rt23...
Is there anything in alsa-* that depends on which _kernel_ is available at compile time?
I have been trying to see if I can figure _anything_ out of this...
A diff of 2.6.29 (last known working) against 2.6.31.12 reveals something that might have an influence on the problem:
in snd_hdsp_create_hwdep there are two lines added:
- hw->ops.open = snd_hdsp_hwdep_dummy_op; hw->ops.ioctl = snd_hdsp_hwdep_ioctl;
- hw->ops.release = snd_hdsp_hwdep_dummy_op;
And snd_hdsp_hwdep_dummy_op just returns 0...
Other differences between the two files (not that many) seem irrelevant to me.
I imagine this is what is causing the difference in behavior (hwdep fails). Any suggestions on what I could try to fix this?
Thanks for any help!
-- Fernando
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, 2010-02-22 at 23:51 +0000, Fernando Lopez-Lezcano wrote:
On Tue, 2010-02-16 at 17:58 -0800, Fernando Lopez-Lezcano wrote:
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering,
[MUNCH]
I have been trying to see if I can figure _anything_ out of this...
A diff of 2.6.29 (last known working) against 2.6.31.12 reveals something that might have an influence on the problem:
in snd_hdsp_create_hwdep there are two lines added:
- hw->ops.open = snd_hdsp_hwdep_dummy_op;
Hmmm, looks like snd_hdsp_hwdep_dummy_op is not passing back the hdsp->hwdep structure to the open call at all (returning 0 is not enough from the description of the alsa api). That would explain what is happening, most probably no ioctls are found...
Am I on the right track? -- Fernando
hw->ops.ioctl = snd_hdsp_hwdep_ioctl;
- hw->ops.release = snd_hdsp_hwdep_dummy_op;
And snd_hdsp_hwdep_dummy_op just returns 0...
Other differences between the two files (not that many) seem irrelevant to me.
I imagine this is what is causing the difference in behavior (hwdep fails). Any suggestions on what I could try to fix this?
Thanks for any help!
On Tue, 2010-02-23 at 00:16 +0000, Fernando Lopez-Lezcano wrote:
On Mon, 2010-02-22 at 23:51 +0000, Fernando Lopez-Lezcano wrote:
On Tue, 2010-02-16 at 17:58 -0800, Fernando Lopez-Lezcano wrote:
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering,
[MUNCH]
I have been trying to see if I can figure _anything_ out of this...
A diff of 2.6.29 (last known working) against 2.6.31.12 reveals something that might have an influence on the problem:
in snd_hdsp_create_hwdep there are two lines added:
- hw->ops.open = snd_hdsp_hwdep_dummy_op;
Hmmm, looks like snd_hdsp_hwdep_dummy_op is not passing back the hdsp->hwdep structure to the open call at all (returning 0 is not enough from the description of the alsa api). That would explain what is happening, most probably no ioctls are found...
Am I on the right track?
Argh. I was looking at the diff backwards (DOH!). The ops.open and ops.release ioctl calls are _missing_ in the 2.6.31.12 tree.
-- Fernando
hw->ops.ioctl = snd_hdsp_hwdep_ioctl;
- hw->ops.release = snd_hdsp_hwdep_dummy_op;
And snd_hdsp_hwdep_dummy_op just returns 0...
Other differences between the two files (not that many) seem irrelevant to me.
I imagine this is what is causing the difference in behavior (hwdep fails). Any suggestions on what I could try to fix this?
Thanks for any help!
On Tue, 2010-02-23 at 00:20 +0000, Fernando Lopez-Lezcano wrote:
On Tue, 2010-02-23 at 00:16 +0000, Fernando Lopez-Lezcano wrote:
On Mon, 2010-02-22 at 23:51 +0000, Fernando Lopez-Lezcano wrote:
On Tue, 2010-02-16 at 17:58 -0800, Fernando Lopez-Lezcano wrote:
Hey, has anyone been seeing strange behavior from this combination?
kernel 2.6.31.x rt20 + alsa 1.0.22 userland RME card (pcmcia card + multiface)
hdspmixer is not doing the right thing (does not initialize the card in a way in which playback works), it does not see the hwdep interface (or something like that) and disables metering,
[MUNCH]
I have been trying to see if I can figure _anything_ out of this...
A diff of 2.6.29 (last known working) against 2.6.31.12 reveals something that might have an influence on the problem:
in snd_hdsp_create_hwdep there are two lines added:
- hw->ops.open = snd_hdsp_hwdep_dummy_op;
Hmmm, looks like snd_hdsp_hwdep_dummy_op is not passing back the hdsp->hwdep structure to the open call at all (returning 0 is not enough from the description of the alsa api). That would explain what is happening, most probably no ioctls are found...
Am I on the right track?
Argh. I was looking at the diff backwards (DOH!). The ops.open and ops.release ioctl calls are _missing_ in the 2.6.31.12 tree.
The attached patch starts to make a difference (it restores the two missing ops in hw->ops. Once the card is recognized and the firmware is downloaded the pcmcia card + Multiface appears to be functional. Cool.
...
Now, recognizing the card is not working fully (Fedora 11 + rt kernel).
From a cold start the card is recognized but it is not fully functional,
a rmmod snd_hdsp followed by a modprobe snd_hdsp fixes that.
Here are the relevant dmesg entries:
Insert pcmcia card, multiface power cycled before that so firmware is not loaded:
---- pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 pci 0000:16:00.0: reg 10 32bit mmio: [0x000000-0x00ffff] RME Hammerfall DSP 0000:16:00.0: enabling device (0000 -> 0002) RME Hammerfall DSP 0000:16:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ALSA sound/pci/rme9652/hdsp.c:679: Hammerfall-DSP: iobox found after 2260ms! ALSA sound/pci/rme9652/hdsp.c:831: Hammerfall-DSP: wait for FIFO status <= 0 failed after 30 iterations RME Hammerfall DSP 0000:16:00.0: firmware: requesting multiface_firmware_rev11.bin ALSA sound/pci/rme9652/hdsp.c:696: Hammerfall-DSP: loading firmware ALSA sound/pci/rme9652/hdsp.c:729: Hammerfall-DSP: finished firmware loading ALSA sound/pci/rme9652/hdsp.c:659: Hammerfall-DSP: no Digiface or Multiface connected! ALSA sound/pci/rme9652/hdsp.c:659: Hammerfall-DSP: no Digiface or Multiface connected! ALSA sound/pci/rme9652/hdsp.c:659: Hammerfall-DSP: no Digiface or Multiface connected! ALSA sound/pci/rme9652/hdsp.c:659: Hammerfall-DSP: no Digiface or Multiface connected! ----
So, the firmware is loaded (apparently) but hdsp_check_for_iobox does not see the Multiface. But the devices appear to be there (card #1):
---- $ cat /proc/asound/devices 2: : timer 3: : sequencer 4: [ 0- 1]: digital audio playback 5: [ 0- 0]: digital audio playback 6: [ 0- 0]: digital audio capture 7: [ 0- 0]: hardware dependent 8: [ 0] : control 9: [ 1- 0]: raw midi 10: [ 1- 0]: digital audio playback 11: [ 1- 0]: digital audio capture 12: [ 1- 0]: hardware dependent 13: [ 1] : control ----
Starting hdspmixer prints:
---- $ hdspmixer
HDSPMixer 1.6 - Copyright (C) 2003 Thomas Charbonnel thomas@undata.org This program comes with ABSOLUTELY NO WARRANTY HDSPMixer is free software, see the file COPYING for details
Looking for HDSP cards : Card 0 : HDA Intel at 0xfe020000 irq 17 Card 1 : RME Hammerfall DSP + Multiface at 0xc0000000, irq 16 Multiface found ! 1 Hammerfall DSP card found. Initializing default presets ----
Everything seems to be there but if I start jackd it starts fine but I get no sound from the outputs.
Something has not been initialized properly. I get this at some point:
---- ALSA sound/pci/rme9652/hdsp.c:4589: Hammerfall-DSP: firmware needs to be uploaded to the card. ----
Now close jack, hdspmixer. /sbin/rmmod snd_hdsp /sbin/modprobe snd_hdsp
---- RME Hammerfall DSP 0000:16:00.0: PCI INT A disabled RME Hammerfall DSP 0000:16:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ALSA sound/pci/rme9652/hdsp.c:679: Hammerfall-DSP: iobox found after 0ms! ALSA sound/pci/rme9652/hdsp.c:5106: Hammerfall-DSP: Firmware already present, initializing card. ----
After that jackd is happy and the card works... Any help appreciated!! -- Fernando
On Tue, Feb 23, 2010 at 3:48 PM, Fernando Lopez-Lezcano nando@ccrma.stanford.edu wrote:
ALSA sound/pci/rme9652/hdsp.c:831: Hammerfall-DSP: wait for FIFO status
<= 0 failed after 30 iterations
this is bad, and i think may be related to your issues. this timing-sensitive loop has always been a problem. it probably just worked the 2nd time you tried a firmware load (by good luck).
--p
participants (2)
-
Fernando Lopez-Lezcano -
Paul Davis