[alsa-devel] Issues with HDSPM
Hello,
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
# amixer cget numid=3 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0
# amixer cset numid=2 5 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=5
# amixer cget numid=6 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000
When switching to a PCI version of the card, the kernel completely crashes on boot.
And with [2], there is another issue which unfortunately hasn't been merged yet and still exists in the current release.
Regards, Andre
[1] http://sourceforge.net/mailarchive/message.php?msg_id=27520432 [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006723.html
On Mon, Jun 06, 2011 at 09:04:25PM +0200, Andre Schramm wrote:
Hello,
Hi!
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
Unfortunately, I don't happen to have a MADI card, but Fredrik has. Fredrik, can you confirm the problem?
At least my RayDAT can be perfectly set to all sample rates via alsamixer, and the code for setting sample rates isn't device specific, so I'd expect it to work on MADI, too.
When switching to a PCI version of the card, the kernel completely crashes on boot.
We'd need a crash report. Best is to blacklist the kernel module, boot the machine and then trying to load the module, maybe on a console.
If need be, we can meet and fix the problem on-site, I'm living close to your place.
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006723.html And with [2], there is another issue which unfortunately hasn't been merged yet and still exists in the current release.
Could you try this patch? (for your convenience, I've also attached it)
diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index 949691a..6649aed 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -1143,7 +1143,7 @@ static int hdspm_external_sample_rate(struct hdspm *hdspm)
/* if wordclock has synced freq and wordclock is valid */ if ((status2 & HDSPM_wcLock) != 0 && - (status & HDSPM_SelSyncRef0) == 0) { + (status2 & HDSPM_SelSyncRef0) == 0) {
rate_bits = status2 & HDSPM_wcFreqMask;
Cheers
On 06/07/2011 08:33 AM, Adrian Knoth wrote:
We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 When switching to a PCI version of the card, the kernel completely crashes on boot.
I just noticed that the driver in the 1.0.24 release tarball doesn't contain the latest fixes we already have in the git repo.
I reckon the PCI version has an "unknown" revision ID. We added a default case a couple of month ago to prevent the kernel from crashing:
default: snd_printk(KERN_ERR "HDSPM: unknown firmware revision %x\n", hdspm->firmware_rev); return -ENODEV; }
I suggest you use this file instead of the 1.0.24 tarball:
http://git.alsa-project.org/?p=alsa-kernel.git;a=blob_plain;f=sound/pci/rme9...
If you send me the revision ID of your PCI MADI card, I'll come up with a patch.
HTH
On Tue, 7 Jun 2011 08:33:05 +0200 Adrian Knoth adi@drcomp.erfurt.thur.de wrote:
When switching to a PCI version of the card, the kernel completely crashes on boot.
We'd need a crash report. Best is to blacklist the kernel module, boot the machine and then trying to load the module, maybe on a console.
I will have access to the hardware again on Friday, I'm going to provide some more details then. I was trying to set up a kdump environment, but haven't been doing much kernel hacking yet.
If need be, we can meet and fix the problem on-site, I'm living close to your place.
That would be great, we're heavily using the MADI cards. But maybe we can figure it out online.
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006723.html And with [2], there is another issue which unfortunately hasn't been merged yet and still exists in the current release.
Could you try this patch? (for your convenience, I've also attached it)
Thanks. A colleague of mine found this one and we used to patch it by hand till now. But it would be great if this would go upstream. :)
Regards, Andre
On 06/06/2011 09:04 PM, Andre Schramm wrote:
Hello,
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
confirmed with 2.6.39.
this is a regression iirc, i think it used to work in 2.6.37...
adi, i can test patches if you want, or you can have ssh access if it helps.
On 06/07/2011 10:02 AM, Jörn Nettingsmeier wrote:
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
confirmed with 2.6.39. this is a regression iirc, i think it used to work in 2.6.37...
Very likely, the code between 2.6.38 and 2.6.39 changed more or less completely.
adi, i can test patches if you want, or you can have ssh access if it helps.
ssh would be good. Together with Andre, it might be worth checking on-site that the resulting sample rate is indeed correctly reported by external equipment.
Andre, JFTR: don't use hdspmixer from the tarball, go directly for the git repo (alsa-tools) until 1.0.24.2 is released.
Cheers
On 06/07/2011 11:45 AM, Adrian Knoth wrote:
On 06/07/2011 10:02 AM, Jörn Nettingsmeier wrote:
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
confirmed with 2.6.39. this is a regression iirc, i think it used to work in 2.6.37...
Very likely, the code between 2.6.38 and 2.6.39 changed more or less completely.
adi, i can test patches if you want, or you can have ssh access if it helps.
ssh would be good. Together with Andre, it might be worth checking on-site that the resulting sample rate is indeed correctly reported by external equipment.
Andre, JFTR: don't use hdspmixer from the tarball, go directly for the git repo (alsa-tools) until 1.0.24.2 is released.
for the record, we just worked on my machine, and the problem could not be reproduced again. what i think happens is:
* when you go higher than 48k, the card reduces its channels count, first to 32, and then, above 96k, to 16 channels i/o. * when something is using the card, this reconfiguration might be prevented, so the card refuses to increase the sample rate.
i can switch to 192k no problem, but if i start jack while at 48k, i can only go down, not up. my guess is that i had a half-dead jack around when i tried to reproduce your issue. andre, can you confirm you do not have any processes running on the card when the problem occurs? i guess lsof /dev/snd/* might be useful...
best,
jörn
the HDSPM driver seems to be broken in the current ALSA release. We're using CentOS 5 with 2.6.33.9-rt31.64.el5rt and ALSA 1.0.24 compiled from source, the card is a PCIe Hammerfall DSP MADI (rev d2). As already mentioned in [1], the card operates in master mode, but the system clock mode can't be set to anything higher than 48kHz.
i can switch to 192k no problem, but if i start jack while at 48k, i can only go down, not up. my guess is that i had a half-dead jack around when i tried to reproduce your issue. andre, can you confirm you do not have any processes running on the card when the problem occurs? i guess lsof /dev/snd/* might be useful...
There's an easier way to acquire this information:
$ cat /proc/asound/default/pcm0*/sub0/status
If it reads "closed", then nobody is using the card, otherwise, there would be an entry for owner_pid, thus preventing the card to change clock modes outside the multiples of 32/44.1/48 (*1, *2 or *4 depending on SS/DS/QS).
Ciao
On Tue, 07 Jun 2011 14:48:02 +0200 Adrian Knoth adi@drcomp.erfurt.thur.de wrote:
There's an easier way to acquire this information:
$ cat /proc/asound/default/pcm0*/sub0/status
I wouldn't swear it, but I'm fairly sure no one was using the card. I'll check on Friday and get back to you.
Regards, Andre
On Tue, 7 Jun 2011 18:52:11 +0200 Andre Schramm andre.schramm@iosono-sound.com wrote:
On Tue, 07 Jun 2011 14:48:02 +0200 Adrian Knoth adi@drcomp.erfurt.thur.de wrote:
There's an easier way to acquire this information:
$ cat /proc/asound/default/pcm0*/sub0/status
I wouldn't swear it, but I'm fairly sure no one was using the card. I'll check on Friday and get back to you.
Everything was reported as CLOSED. I tested again with 3 cards in combinations of 2 (2x PCI and PCI and PCIe mixed), the results are attached. Setting the rate on the PCIe card worked fine, but the PCI versions reported bogus rates. I built ALSA again from the sound-2.6 tree Adrian pointed me to with the latest hdspm.c. One of the PCI cards had 205 as firmware revision, I added it acc. to [1] as HDSPM_MADI_OLDEST_REV, which made the module work for the card.
Cheers, Andre
[1] http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=blobdiff;f=s...
participants (3)
-
Adrian Knoth -
Andre Schramm -
Jörn Nettingsmeier