Hi,
there seem to be quite some buggy via8233-chipsets around (they are handled by
the via82xx-driver). I'd propse a workaround in the drivers.
Problem description:
The sound in most applications is so noisy that you can hardly hear the
music. This problem applies to all alsa versions I have tested (some have
noise on one channel only). The only distribution on which I got sound
working was SuSE 8.1 (with a 2.4.19-Kernel patched by them). However I have
not looked at what changes they made to the alsa code. The noise seems to be
played about every time the soundcard's buffer is refreshed (more exactly:
playing noise seems to be tied to the chip's interrupts (one snippet of white
noise or one click or whatever is played every time the interrupt handler is
called)). This is however just an impression and may be wrong.
Possible cause:
As far as I can tell, the 8233-chip (at least the one in my notebook) or some
other chip involved does not properly support sample-rates other than 48000.
While most sample rates do work, some don't (e.g. 44.1 kHz which most apps
try to use)
Some other people suggest things like forcing apps to use 48kHz (see e.g.
http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=VIA&card=&chip=via8235&module=via82xx)
too. This actually works and leaves the impression that the card should be
forced to 48k whenever possible.
Another theory suggests to look at the pcm buffer stuff (because noise seems
to be tied to hardware interrupts). Maybe the interrupt to change buffers is
triggered at the wrong moment. Have not investigated this and does not seem
too probable to me.
Suggestion:
The problem can be solved by forcing the chip to always play at 48 kHz. I'm
not familiar with the code so I do not know where the best place to change it
would be, One possibility, however, is to add the following line to
sound/pci/via82xx.c in method snd_via82xx_mixer_new around line 1485 (for the
alsa version shipped with linux kernel 2.5.69):
if (chip->chip_type != TYPE_VIA686) {
/* use slot 10/11 */
snd_ac97_update_bits(chip->ac97, AC97_EXTENDED_STATUS, 0x03 << 4, 0x03
<<4);
// BEGIN OF ADDED CODE
// clear the bit that allows sampling rates other than 48000
if (chip->chip_type != TYPE_VIA8233) {
snd_ac97_update_bits(chip->ac97, AC97_EXTENDED_STATUS,
AC97_EA_VRA , 0x00);
}
// END OF ADDED CODE
}
If there are objections or if most 8233-chips work correctly, this could be
#ifdef'ed with some kind of CONFIG_WORKAROUND_BUGGY8233 option or the like.
Although this code snippet does not add any regressions for me, it is clear
that it is just a workaround. I'd of course be happy if someone found a
"real" solution.
If there are any questions, I'll be happy to provide more information
Cheers,
Frank
---- appendix: output of lspci -nvv for the device in question
00:11.5 Class 0401: 1106:3059 (rev 30)
Subsystem: 14ff:0403
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 5
Region 0: I/O ports at 1000 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
