[原创]科普板载声卡知识

[lumi]

论坛上经常有TX提出自己的板载声卡方面的问题，但提问题时往往不能抓住重点。因此，TXM很有必要了解一下板载声卡的基本知识。
1、板载声卡从架构上分成两个部分，一是南桥芯片里的controller，一是主板上的codec。controller从内存里抓取音频数据，然后发给codec播放；或者codec从外界录音，录下的音频数据通过controller存储到内存里。通过lspci命令得到声卡信息只是controller的信息，因为controller是一个pci设备，codec不是。常见的controller厂商包括Intel, ATI等芯片组厂商。常见的codec厂商包括Realtek, Analog, Cmedia等。
2、板载声卡的规格目前有两种，一种是比较老的AC97规格，一个是目前流行的HDA(High Definition Audio)规格。AC97规格太老了，很多厂商逐渐不再出AC97的codec芯片，所以如果TX的AC97规格的codec出现问题，可能解决起来会比较麻烦。(联系系统厂商是解决问题的一个很好的途径)
3、声卡的工作方式和主板密切相关。相同的codec芯片在不同的主板上都会有不同的工作状况。下面以HDA为例说明问题。在HDA codec内部，有很多工作部件，其中有一种部件叫做pin complex，用于连接主板上的耳机插孔或者笔记本内部的音箱。Pin complex的连接方式是可以随意配置的，每种配置都需要用命令初始化正确才能正常工作。举个例子，如果主板厂商在设计主板电路时，把某个pin complex（我们假设为A）连到耳机插孔上，把另一个pin complex（我们假设为B）连到内部音箱上，但codec厂商默认的连接可能是A和B都是连接到耳机插孔上(多声道的声卡会有几个耳机插孔)，那就会出现内部音箱不能发声的问题。 而之所以会出现这个问题，可能就是因为主板厂商在设计主板电路时，并没有按照相应的电路设计重新对codec进行初始化。
4、很多情况下，TXM的计算机都是装双系统的。而且在Linux下出现的声卡问题在Windows下却能正常工作。产生这种情况的主要原因在于很多主板厂商在量产的时候只进行了Windows的测试，而忽略了Linux测试。
5、Linux下的声卡的音质问题也是很多TX诟病的地方。在Linux下音质问题应该还有很长一段路走。音质不好也是有多方面原因的。播放一首音乐，首先需要播放器解码，解完之后的PCM编码再发给声卡驱动，最后通过controller交给codec播放。Linux和Windows相比，从底层往上层看，codec和controller这两种硬件对两个系统来说是一样的。所以对音质差别产生贡献的就在于播放器和声卡驱动。声卡驱动做的事情其实不多，它只是负责从上层接收PCM数据发给声卡播放，所以，音质的好坏关键在于播放器，或者说在于播放器的解码插件。因为Linux的开源特点，很多多媒体厂商并不愿意提供Linux的解码器，譬如大名鼎鼎的杜比就只提供windows下的解决方案。
6、发现声卡问题怎么办呢？ 首先查看音量控制里相关的选项是否都打开。如果音量控制没有问题，那很大的可能就是驱动程序的问题。自己无法解决可以向主板厂商寻求帮助，或者在论坛里寻求帮助。在寻求帮助时，对于HDA来说，/proc/asound/card0/codec#?是很重要的信息。

[andrew_t]

排版太差

[xihai2100]

还是学习了，，，谢谢

[mason105]

lumi兄专业，专业的！！顶个

[hamaburg]

这帖子对我很有启发：0)


顶下：D

[learcat]

学习了，可我的还是AC‘97

[fortruth]

看了再收藏

[d5ghost]

学了很多！谢谢lumi。

[skyx]

认正学习中.............

正好手上有alc665的datasheet

没仔细看alc665各个register 的定义, alc665 的pin assignments貌似是固定的

如果hd audio 的pin assignments 可以设定(我想应该就是楼主所说的pin complex),我想厂商应是改和pin assignments 有关的register,

这些pin assignments register 的初使化是bios完成的吗? 也就是说声卡的pin定义和bios有关?

对于pin assignments不用默认值的主板(alsa 默认?), 我想在win下用通用的驱动也应正常, 那就是说windows驱动可以读到正确的pin assignments信息而linux的alsa 却不能?

综上:

对于不正常的, 要在 /etc/modprobe.d/alsa-base

加入下面的代码：

options snd-hda-intel model=厂商类型

[晶晶守护神]

在linux下能解决多音频流发音就行了 偶要求不高~~~对linux的音质不抱希望~

[skyx]

在linux下能解决多音频流发音就行了

Sharing a device

It is often desirable to be able to share a sound card among several processes running at the same time.

This requires the ability to mix the sound outputs of those processes into a single stream, that is multiplexing.

In order to achieve this with ALSA there are several different cases and techniques.

The cases depend on whether the sound card/chipset supports hardware mixing or not, and whether the processes access the sound card/chipset via the ALSA library, a sound server or OSS emulation.

In the beginning OSS often did not support sharing even if it was supported by the hardware. ALSA drivers, as a rule, will support sharing if the hardware supports it. The ALSA library supports sharing even if the hardware does not support it, but this requires some explicit configuration. For applications that use OSS, the aoss wrapper can make them use ALSA instead, which improves things.

Finally applications that use sound servers like EsounD, polypaudio, aRts, or JACK. most sound servers perform software mixing and support ALSA output.

The individual cases are:

* The card supports hardware mixing.
* The card does not support hardware mixing, but all processes accessing it run applications that use the ALSA library.
* The applications use a sound server to access the card.
* The applications use the OSS API to access the card.



The card supports hardware mixing

This is the best case. Most recent cards support hardware mixing, at least for output, and when they do they support it to up to a maximum number of streams that is so high that it is unlikely to be ever a problem.

If you can the simplest way to ensure sharing is to get a card that supports hardware mixing. Sound cards are cheap, often costing less than the time to implement workarounds.
The card does not support hardware mixing, but all processes accessing it run applications that use the ALSA library

In this case, it is fairly to create an ALSA library configuration file (see the .asoundrc documentation at OpenSrc.org and at ALSA-Project.org) that allows software mixing. This is achieved using the dmix (for output) and dsnoop (for input) plugins, and asym to tie them together. In ALSA library version 1.0.9rc2 and later versions this is already done in the standard configuration files.

There is an example of using them below, and a much more extensive, ready-made, nearly universal 1 or 2 card configuration file that you can most often just drop-in and it will work here.
The applications use a sound server to access the card

Sound servers were mainly created to premix multiple streams for OSS, where even cards that supported hardware mixing did not support multiplexing.

If your system runs a sound servers like EsounD, for GNOME or aRts, for KDE, set the sound server to use ALSA as its output, and applications to use the sound server.

For KDE aRts problems see: here and try using artsdsp to make OSS applications use aRts instead. But it is probably preferable to make them use ALSA directly by using aoss.
The applications use the OSS API to access the card

Some applications cannot use ALSA or a sound server, but only the OSS API. In that case you can often make them use ALSA using the aoss wrapper. Also check these these notes and check careflly the description of non blocking options in these other notes.
Examples of ALSA lib configurations to use the software mixing plugins
Simple output only sharing example

# The top level shared pseudo device, with both PCM and CTL interfaces
# The device names "default", "dsp0", "mixer0" have conventional meanings.

# The top level shared pseudo device, with both PCM and CTL interfaces
# The ALSA default is "!default", but many programs like XMMS and aoss
# assume "dsp0" as default name for PCM and "mixer0" for CTL.

# Amazingly, XMMS has problems if one defines 'pcm.dsp0' to be
# 'plug' for 'pcm.asym0' and not directly as 'asym0'.

pcm.!default { type plug;
slave.pcm "dmix0"; }
ctl.!default { type hw; card 0; }

pcm.dsp0 { type plug;
slave.pcm "dmix0"; }
ctl.dsp0 { type hw; card 0; }
ctl.mixer0 { type hw; card 0; }

########################################################################

# Buffering (period time defaults to 125000 usecs).

# Size of period, expressed either in usec or byte units:
# period_time USECS
# period_size BYTES

# Size of buffers, expressed either in period, usec, or byte units:
# periods PERIODS
# buffer_time USECS
# buffer_size BYTES

# The ALSA docs have examples with 'period_time' set to 0,
# when 'period_size' and 'buffer_size' are used instead,
# but this can cause trouble in later releases of ALSA.

# For OSS compatibility, 'period_size' and 'buffer_size'
# should be powers of 2. Also, many cards cannot accept
# a 'period_size' much greater than 4096, so 4096 is safe.
# On my VIA 8233A, any value for 'period_time' greater than
# 85333 usecs (precisely!) causes hiccups in sound output.
# Why? At 48kHz, 85333 usec are are just over 4096 bytes/channel.

pcm.dmix0 { type dmix;
ipc_key 13759;

slave.pcm "hw:0,0";
slave.channels 2;

slave.rate 48000;
slave.period_size 4096;
slave.buffer_size 16384;

slave.period_time 84000;
slave.buffer_time 340000;

# Map only the first two channels
bindings.0 0;
bindings.1 1; }

Sharing both input and output

To the output only example add:

# The top level shared pseudo device, with both PCM and CTL interfaces
# The ALSA default is "!default", but many programs like XMMS and aoss
# assume "dsp0" as default name for PCM and "mixer0" for CTL.

# Amazingly, XMMS has problems if one defines 'pcm.dsp0' to be
# 'plug' for 'pcm.asym0' and not directly as 'asym0'.

pcm.!default { type asym;
capture.pcm "dsnoop0";
playback.pcm "dmix0"; }
ctl.!default { type hw; card 0; }

pcm.dsp0 { type asym;
capture.pcm "dsnoop0";
playback.pcm "dmix0"; }
ctl.dsp0 { type hw; card 0; }
ctl.mixer0 { type hw; card 0; }

########################################################################

pcm.asym0 { type asym;
capture.pcm "dsnoop0";
playback.pcm "dmix0"; }

pcm.dsnoop0 { type dsnoop;
ipc_key 13758;
slave.pcm "hw:0,0"; }

This defines a virtual ALSA PCM device called asym0. This device is capable of mixing several playback streams and sharing one capture stream amongst several applications. To get automatic samplerate conversion, etc, we defined the device dmix0 which uses alsa's plug plugin.

Furthermore we defined a device called !default. This is equivalent to dsp0. The special name !default makes this device the default device for all well coded ALSA apps (sadly not too many are well coded).

And last we defined a device called dsp0. This device is used by the aoss script from the alsa-oss package.

First of all we test this basic setup with the standard ALSA aplay tool. You will need a .wav file for this test. If you have none, create one out of an MP3 with the following command:

mpg123 name.mp3 -w name.wav

With this .wav file we test the dsp0 device now:

aplay -D dsp0 name.wav

This should playback the .wav. Even if you run this command in a second terminal at the same time, because the dsp0 device does the mixing. Because we also defined the default alsa device !default to use asym0, you should also be able to run the command without the -D dsp0 parameter:

aplay name.wav

Not all apps honour the default device though. MPlayer for example is one of them.

To test this setup with MPlayer use:

mplayer -ao alsa1x:dsp0 name.avi

So, now is the time to test all your desired alsa apps to work with this setup.

* Some will need to be told explicitly to use dsp0.
* Others will happily use the default.

If some ALSA apps behave badly with dsp0 (crackles, stutter), check the dmix plugin configuration page. It has quite a bit of troubleshooting. Tips: look at the samplerates of the slave, maybe play with the period_size parameter, etc.; in particular many cards have limits on the period_size, usually to 4096 bytes.

Some applications use mmap'ed audio data transfer. If your application complains about not being able to use mmap, then play around with the mmap_emulation setting in the pcm.dsp0 definition.

Some applications and/or some cards will simply not work in mmap mode, so try disabling it.

[rgaobj]

其实个人感觉，ALSA还是比OSS的效果更好，很多人说OSS的驱动更稳定，但其实ALSA正确配置后稳定性也非常好。

[晶晶守护神]

学习中 OSS有爆炸的声音~~

[skyx]

偶要求不高~~~对linux的音质不抱希望~

Potential sound quality issue checklist

Sound hardware depends on particularly tight realtime constraints, and this can give rise to a number of issues.

Sound hardware is often also designed and manufactured without much care, especially in the case on motherboard chipsets.

There can be in particular many sound quality issues related to latency, and these are discussed in a separate document on Linux sound latency issues.

The sound quality HOWTO also has a lot of advice on quality issues.

These are issues that are generally possible, and not necessarily related to the specific chipset or sound card used:

BIOS: disable PCI Delay Transaction
For better performance and latency this BIOS setting should be enabled, but there are enough cards that don't support it well that if there are problems one should try to disable it.
BIOS: change IRQ sharing
Ideally your sound chipset should be on a dedicated IRQ, but this is often not possible on a system with many chipsets. Unfortunately some chipsets do not share IRQs well, and it is difficult to know in advance. So experiment with rearranging IRQ assignments in the BIOS, and/or swapping PCI cards around, as IRQs are assigned to slots, not cards as such.
To ensure your explicit IRQ assignments it is probably necessary to disable in the BISO the PnP OS setting (usually a good idea regardless) and to use the kernel boot parameter pci=biosirq.
System: tweaking the PCI latency timers
If your sound is metallic or crackly or slightly distorted perhaps you need to set the PCI latency times of some PCI card to less aggressive values, for example with the command:

setpci -v -s '*:*' latency_timer=20

(but reset the latency timer to 0 for the host bridge, usually with id 00:00.0). There are more details on this in the notes on sound latency. Another possible workaround is adding Option "PciRetry" "true" to the X server configuration.
System: ensure proper MTRR
The MTRR settings for your system can matter greatly to the amount of bus traffic, and this can impact the performance and quality of your sound. Check the plausibility of the contents of /proc/mtrr; main memory should be write-back, and the frame buffer of video cards (at some very high address) should be write-combinining. There are some documents and articles on the WWW that discuss MTRR settings.
System: ensure the ATA/IDE drives are on DMA
If the ATA/IDE drives (usually hard discs) are not using DMA then IO may take a lot of CPU time and this can impact very strongly sound quality. Use hdparm -v to check if DMA is enabled.
ALSA: fragment_size <= 4096
Many cards, in particular of the AC97 sort, have low limits on the size of sound samples they can accept, usually only a few kilobytes. This means that the fragment size for that card should be set to be low. This can be done inside the program writing sound data to the card, but it can also be done by defining a suitable plugin in /etc/asound.conf with the desired fragment size.
ALSA: ensure volume is less than 70%
Many cards have somewhat poor internal mixers and amplifiers, and sound will be distorted at high volume levels. Some cards have problems with too high levels of the master volume, some with too high volumes of the individual channel volumes, some with both. Some will have problems with volume setting higher than 50%, some with setting higher than 65-70%.
ALSA: check the number of channels in /etc/asound.conf
If you specify the wrong number of channels in a virtual device definition the resulting sound can be quite crackly. Some cards for example don't have a 2 channel mode, they just work in 5.1 channel mode.
ALSA: ensure all non necessary inputs are muted
Sometimes the controls for input devices are left unmuted; in theory this should affect the sound, especially if nothing is muted into them. But unmuted recording controls can collect electrical noise which gets mixed into the output. Makes sure that all non necessary input channels are muted; merely setting the capture volume to zero is not enough.
ALSA: use external amplifier and line out
To avoid sound distortion problems it is often a good idea to use an external amplifier, instead of relying on the internal amplifier on the card. Several ALSA drivers allow disabling the internal amplifier by unmuting the control called External Amplifier. If this is not possible or does not work, one can plug the external amplifier into the line-out socket of the card, if any.
ALSA: use external preamp for microphone
There are many, many issues related to mismatches in impedance and other electrical characteristics between microphones and cards. Sometimes recording is better if one uses the Mic Boost control for the microphone channel, but usually quality will not be optimal. If quality is desired, an external microphone amplifier is probably# a lot better.

[phonen]

学习