16 Feb
2010
16 Feb
'10
9:58 p.m.
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
17 Feb
17 Feb
1:30 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/02/2010 02:58, Fernando Lopez-Lezcano a écrit :
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
Hi,
I'm actually using a similar combination on my gentoo without problem
(PCI card).
AFAIK the only difference between 2.6.30 and 2.6.31 for the hdsp is a
patch I made allowing the firmware to be built inside the kernel. It
should not have this kind of side-effect.
I'll check on my notebook with the PCMCIA card as soon as I can.
If you're using a custom built kernel you might want to try with the
firmware built-in.
- --
Raphaël Doursenaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt7fwAACgkQaZKmNAdXaVXEIQCfbBal0dMkaBHlMpdJDfy/e9u2
W/0AoL6ASo0FmMdHrDP7xv9rHpoAiyer
=ZDOq
-----END PGP SIGNATURE-----
4:54 p.m.
On Wed, 2010-02-17 at 06:30 +0100, Raphaël Doursenaud wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/02/2010 02:58, Fernando Lopez-Lezcano a écrit :
The difference is between 2.6.29 and > 2.6.29 (I tested with 31 but at
least another of my users is having a problem with 30).
Firmware seems to be loading fine.
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?
Hi,
I'm actually using a similar combination on my gentoo without problem
(PCI card).
AFAIK the only difference between 2.6.30 and 2.6.31 for the hdsp is a
patch I made allowing the firmware to be built inside the kernel. It
should not have this kind of side-effect. I'll check on my notebook with the PCMCIA card as
soon as I can.
Thanks, would be good to know.
If you're using a custom built kernel you might
want to try with the
firmware built-in.
It does not look like it is the firmware, I think that when the firmware
does not load the card does not even appear in alsa. The problem I'm
seeing is userland confused about what the kernel can do (or at least it
appears to be that way). Very weird.
-- Fernando
6:51 p.m.
--- On Wed, 2/17/10, Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> wrote:
From: Fernando Lopez-Lezcano
<nando(a)ccrma.Stanford.EDU>
Subject: Re: [LAD] 2.6.31.x vs. rme vs. alsa 1.0.22?
To: "Raphaël Doursenaud" <rdoursenaud(a)free.fr>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Wednesday, February 17, 2010, 3:53 PM
On Wed, 2010-02-17 at 06:30 +0100,
Raphaël Doursenaud wrote:
without problem
could it be the PCMCIA part ? I have the PCI version and both 2.6.31.x and 2.6.32 are
working as they should with my RME HDSP and Multiface II.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/02/2010 02:58, Fernando Lopez-Lezcano a écrit
:
> 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?
Hi,
I'm actually using a similar combination on my gentoo (PCI card).
AFAIK the only difference between 2.6.30 and 2.6.31
for the hdsp is a
patch I made allowing the firmware to be built
inside
the kernel. It
should not have this kind of side-effect.
The difference is between 2.6.29 and > 2.6.29 (I tested
with 31 but at
least another of my users is having a problem with 30).
Firmware seems to be loading fine.
I'll check on my notebook with the PCMCIA
card as soon
as I can.
Thanks, would be good to know.
If you're using a custom built kernel you
might want
to try with the
firmware built-in.
It does not look like it is the firmware, I think that when
the firmware
does not load the card does not even appear in alsa. The
problem I'm
seeing is userland confused about what the kernel can do
(or at least it
appears to be that way). Very weird.
-- Fernando
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7:25 p.m.
James,
could it be the PCMCIA part ? I have the PCI version
and both 2.6.31.x and 2.6.32 are working as they should with my RME HDSP and Multiface II.
It's pretty much a regression in the ALSA control part. Unfortunately I
don't have any HDSP devices anymore, so I cannot test it.
The ALSA controls for the hdsp(m) series are pretty much broken anyway.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
22 Feb
22 Feb
7:21 p.m.
On Thu, 2010-02-18 at 00:25 +0100, Florian Faber wrote:
James,
Rats... anyway I could help debug this? It is broken...
could it be the PCMCIA part ? I have the PCI
version and both 2.6.31.x and 2.6.32 are working as they should with my RME HDSP and
Multiface II.
It's pretty much a regression in the ALSA control part. Unfortunately I
don't have any HDSP devices anymore, so I cannot test it. The ALSA controls for the hdsp(m) series are pretty
much broken anyway.
Irrelevant, it was working before, it is broken now, I presume it can be
fixed so that it works again. Otherwise a lot of boxes out there become
expensive doorstops (not the first this would happen, of course :-)
-- Fernando
7:52 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
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(a)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
8:07 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
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:
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
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(a)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
_______________________________________________
Alsa-devel mailing list
Alsa-devel(a)alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
8:17 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
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!
8:21 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
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:
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
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? > 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!
23 Feb
23 Feb
4:49 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
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:
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).
On Mon, 2010-02-22 at 23:51 +0000, Fernando
Lopez-Lezcano wrote:
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. 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? 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(a)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
5:22 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
On Tue, Feb 23, 2010 at 3:48 PM, Fernando Lopez-Lezcano
<nando(a)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
5:27 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
On 02/23/10 22:22, Paul Davis wrote:
On Tue, Feb 23, 2010 at 3:48 PM, Fernando
Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
I wonder if this happens with the PCI interface as well or if this is
just another CardBus-Fuckup. Once again.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
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).
6:52 p.m.
New subject: [alsa-devel] 2.6.31.x vs. rme vs. alsa 1.0.22?
On Tue, 2010-02-23 at 22:26 +0100, Florian Faber wrote:
On 02/23/10 22:22, Paul Davis wrote:
One test later. Not the same environment, it is a desktop with a pci
card and a digiface (instead of a multiface). 2.6.31.12-rt21 with the
patch that restores functionality to snd_hdsp seems to work fine:
----
$ dmesg | grep -i hdsp
ALSA sound/pci/rme9652/hdsp.c:678: Hammerfall-DSP: iobox found after
0ms!
ALSA sound/pci/rme9652/hdsp.c:830: Hammerfall-DSP: wait for FIFO status
<= 0 failed after 30 iterations
ALSA sound/pci/rme9652/hdsp.c:695: Hammerfall-DSP: loading firmware
ALSA sound/pci/rme9652/hdsp.c:728: Hammerfall-DSP: finished firmware
loading
----
After booting the card seems to work (it was disconnected from the
firewire wire while it was rebooting). But same problem with the wait
for FIFO failing. So maybe it is not so different after all.
-- Fernando
On Tue, Feb 23, 2010 at 3:48 PM, Fernando
Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
I wonder if this happens with the PCI interface as well or if this is
just another CardBus-Fuckup. Once again. 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).
5175
days inactive
5182
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Fernando Lopez-Lezcano -
Florian Faber -
James Warden -
Paul Davis -
Raphaël Doursenaud