Re: [alsa-devel] [Alsa-user] is this card supported by ALSA?
Date: Tue, 15 Jul 2008 19:02:46 +0200 From: rene.herman@keyaccess.nl To: b3zdomny@hotmail.com CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org Subject: Re: [Alsa-user] is this card supported by ALSA?
On 15-07-08 16:42, Rene Herman wrote:
<snip>
Just in case... I did _say_ 'without the --dry-run' but then neglected to actually delete it from the second line here. You _did_ delete it, right?
Off, Rene.
Yes, I did delete '-dry-run'.
In fact, just to be doubly certain, I just re-ran the whole process and additionally ran alsaconf (and again there was a loud 'click' in the speakers when alsaconf loaded the driver):
# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0= 0-0/0: 0x83848384 STS
PCI Subsys Vendor: 0x0000 PCI Subsys Device: 0x0000
Capabilities : -dedicated MIC PCM IN channel- -bass & treble- DAC resolution : 16-bit ADC resolution : 20-bit 3D enhancement : Reserved 29
Current setup Mic gain : +0dB [+20dB] POP path : post 3D Sim. stereo : off 3D enhancement : off Loudness : on Mono output : Mic Mic select : Mic1 ADC/DAC loopback : off
# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs= 0:00 = 0000 0:02 = 0140 0:04 = 8909 0:06 = 8000 0:08 = 8009 0:0a = ffff 0:0c = 150b 0:0e = 805f 0:10 = 805f 0:12 = 9515 0:14 = 9212 0:16 = 8b0b 0:18 = 9212 0:1a = 9010 0:1c = 0000 0:1e = 0000 0:20 = 0000 0:22 = 0000 0:24 = 0000 0:26 = 0000 0:28 = 000f 0:2a = ffff 0:2c = ffff 0:2e = ffff 0:30 = ffff 0:32 = ffff 0:34 = ffff 0:36 = ffff 0:38 = ffff 0:3a = ffff 0:3c = ffff 0:3e = ffff 0:40 = ffff 0:42 = ffff 0:44 = ffff 0:46 = ffff 0:48 = ffff 0:4a = ffff 0:4c = ffff 0:4e = ffff 0:50 = ffff 0:52 = ffff 0:54 = ffff 0:56 = ffff 0:58 = ffff 0:5a = ffff 0:5c = 0000 0:5e = 0000 0:60 = 0000 0:62 = 0000 0:64 = 0000 0:66 = ffff 0:68 = ffff 0:6a = ffff 0:6c = ffff 0:6e = ffff 0:70 = ffff 0:72 = ffff 0:74 = ffff 0:76 = ffff 0:78 = ffff 0:7a = ffff 0:7c = ffff 0:7e = 8384
# aplay -D hw:AudioPCI /usr/share/sounds/startup3.wav= Playing WAVE '/usr/share/sounds/startup3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo (with silence)
# speaker-test=
speaker-test 1.0.16
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise (with silence)
xmms plays, you can see the level bars pumping, but with silence.
checking /etc/modprobe.d /blacklist: es1371 is blacklisted.
rebooting.
# speaker-test= speaker-test 1.0.16
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave Playback open error: -2,No such file or directory
# aplay -D hw:AudioPCI /usr/share/sounds/startup3.wav= ALSA lib pcm_hw.c:1351:(_snd_pcm_hw_open) Invalid value for card aplay: main:564: audio open error: No such device
/var/log/boot & dmesg (from after reboot) attached.
Best regards,
Landis
cheers,
Landis
_________________________________________________________________ Making the world a better place one message at a time. http://www.imtalkathon.com/?source=EML_WLH_Talkathon_BetterPlace
On 15-07-08 22:28, Landis McGauhey wrote:
Yes, I did delete '-dry-run'.
In fact, just to be doubly certain, I just re-ran the whole process and
I still worry a little bit, since if all's well, you should have seen the "patch -p1" command fail this time (it commenting that the patch seemed already applied) but I'll assume you did see that then. It's unfortunate that the problem with your card seems involved in a way which makes it fairly hard to debug this while not having the card locally to fiddle around with, adding delays between things ...
additionally ran alsaconf (and again there was a loud 'click' in the speakers when alsaconf loaded the driver):
# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0= 0-0/0: 0x83848384 STS
... because, lovely, yet another variant. There is an interface problem between the ES1371 and (supposed) STAC9704 chips on your card and even though that MIGHT not be all the problem (even though the ALSA driver doesn't recognize your AC97 codec due to this, the OSS driver also drives it without any special quirks) this will need to be taken care of first.
With the card locally, the attached is the first thing I'd try. It makes the driver wait around a bit to have the codec recover from reset. Apply it as before, run "make" and "make modules_install" and re-load the snd-ens1371 driver with (as root) "modprobe -r snd-ens1371 && modprobe -r es1371 && modprobe snd-ens1371" after which ALSA sound may or may not work (test through aplay).
(note by the way that for now I'm foregoing any other problems you have with rebooting not loading the correct driver and such -- your dmesg indicated that the OSS es1371 driver was loading even though you said you blacklisted that, so just do the manual modprobe/modprobe -r stuff.)
Please also make sure that, after loading the newly patched snd-ens1371, there's nothing interesting at the end of dmesg -- nothing about timeouts and such. If there is something, please post.
If this doesn't work (likely) I'll just have to sit down and trace AC97 accesses one by one between OSS and ALSA driver as nothing jumped out at me yet.
Rene.
diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c index cd74fb2..5344d3e 100644 --- a/sound/pci/ens1370.c +++ b/sound/pci/ens1370.c @@ -1934,6 +1934,7 @@ static struct es1371_quirk es1371_ac97_reset_hack[] = { { .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_CT5880, .rev = CT5880REV_CT5880_E }, { .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_ES1371, .rev = ES1371REV_CT5880_A }, { .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_ES1371, .rev = ES1371REV_ES1373_8 }, + { .vid = PCI_VENDOR_ID_ECTIVA, .did = PCI_DEVICE_ID_ECTIVA_EV1938, .rev = EV1938REV_EV1938_A }, { .vid = PCI_ANY_ID, .did = PCI_ANY_ID } }; #endif
At Wed, 16 Jul 2008 11:16:32 +0200, Rene Herman wrote:
On 15-07-08 22:28, Landis McGauhey wrote:
Yes, I did delete '-dry-run'.
In fact, just to be doubly certain, I just re-ran the whole process and
I still worry a little bit, since if all's well, you should have seen the "patch -p1" command fail this time (it commenting that the patch seemed already applied) but I'll assume you did see that then. It's unfortunate that the problem with your card seems involved in a way which makes it fairly hard to debug this while not having the card locally to fiddle around with, adding delays between things ...
additionally ran alsaconf (and again there was a loud 'click' in the speakers when alsaconf loaded the driver):
# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0= 0-0/0: 0x83848384 STS
... because, lovely, yet another variant.
Well, from The fact that this is repeated numbers, I guess this is a result of (still) wrong codec communication. Likely the previous number remains to the next read.
I guess my patch did something wrong, too -- at least, waiting for SRC up/down shouldn't be with sleep but a busy loop.
There is an interface problem between the ES1371 and (supposed) STAC9704 chips on your card and even though that MIGHT not be all the problem (even though the ALSA driver doesn't recognize your AC97 codec due to this, the OSS driver also drives it without any special quirks) this will need to be taken care of first.
With the card locally, the attached is the first thing I'd try. It makes the driver wait around a bit to have the codec recover from reset. Apply it as before, run "make" and "make modules_install" and re-load the snd-ens1371 driver with (as root) "modprobe -r snd-ens1371 && modprobe -r es1371 && modprobe snd-ens1371" after which ALSA sound may or may not work (test through aplay).
(note by the way that for now I'm foregoing any other problems you have with rebooting not loading the correct driver and such -- your dmesg indicated that the OSS es1371 driver was loading even though you said you blacklisted that, so just do the manual modprobe/modprobe -r stuff.)
Please also make sure that, after loading the newly patched snd-ens1371, there's nothing interesting at the end of dmesg -- nothing about timeouts and such. If there is something, please post.
Yeah, the kernel messages are really important. Some messages should appear if the codec access timeout occured. Then it can explains why zero is read for many registers.
Takashi
Date: Wed, 16 Jul 2008 13:07:03 +0200 From: tiwai@suse.de To: rene.herman@keyaccess.nl CC: b3zdomny@hotmail.com; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [Alsa-user] is this card supported by ALSA?
<snip>
Well, from The fact that this is repeated numbers, I guess this is a result of (still) wrong codec communication. Likely the previous number remains to the next read.
I guess my patch did something wrong, too -- at least, waiting for SRC up/down shouldn't be with sleep but a busy loop.
<snip>
Yeah, the kernel messages are really important. Some messages should appear if the codec access timeout occured. Then it can explains why zero is read for many registers.
Takashi
Thank you very much for your patience and persistence, Takashi. If we can arrive at a solution it should benefit the entire community as this card, unless I'm mistaken, is very common.
best regards,
Landis
PS -- to Rene & Takashi: today I am taking delivery of an external USB sound card for my old laptop with WinXP (the headphone socket completely wore out from use, the plug falls right out of it!). Wouldn't it be ironic if the new USB unit works with ALSA here on my desktop?!?
_________________________________________________________________ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL...
Date: Wed, 16 Jul 2008 11:16:32 +0200 From: rene.herman@keyaccess.nl To: b3zdomny@hotmail.com CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org Subject: Re: [Alsa-user] is this card supported by ALSA?
On 15-07-08 22:28, Landis McGauhey wrote:
Yes, I did delete '-dry-run'.
In fact, just to be doubly certain, I just re-ran the whole process and
I still worry a little bit, since if all's well, you should have seen the "patch -p1" command fail this time (it commenting that the patch seemed already applied) but I'll assume you did see that then.<snip>
Yes, I did see that and re-installed the patch anyway.
Good afternoon, Rene! Thank you for the new patch and thank you for your persistence and patience-- they are very much appreciated. Just having my first cup of coffee-- it's 0500 here on the Left Coast of the USA. I'll run the new patch and let you know the results.
best regards,
Landis
_________________________________________________________________ Time for vacation? WIN what you need- enter now! http://www.gowindowslive.com/summergiveaway/?ocid=tag_jlyhm
participants (3)
-
Landis McGauhey -
Rene Herman -
Takashi Iwai