Poor support of Intel HDAudio

[guest]

Intel HDAudio CODEC (ALC880) is standard for many modern notebooks and desktops. Only WarpVision? is able to make sound via UniAud? API. All other eComStation multimedia applications are silent.

Dmitry Froloff reminds that it's difficult implement normal support for this adapter because of kernel threads requirement.

Please, inform me, are you going implement normal support for this codec in 2006?

(Eugene Gorbunoff, eCo Software)

[rlalla@…]

Well, I investigated what is wrong with Intel HDA audio in general (combined with Sigmatel codec in my case).

About HDA chipsets: Intel HDA sound systems are always made of two hardware components. The HDA part is always the same and part of the Intel mainboard chipset. It is responsible for memory dma access, data transport and signal processing. The second part is a chip containing A/D, D/A, multiplexers, variable gain amplifiers,... This chip exist from different manufacturers (like Realtek, Sigmatel) and at different price and quality levels.

About UniAud? driver: UniAud?32.sys contains the actual collection of sound drivers ported from Linux/ALSA, and can be called directly through UniAud? api. So in case Warpvision plays saudio, the core sound drivers are ok. UniAud?16.sys is the translation layer from UniAud?32.sys to the MMOS2 multimedia subsystem. For Intel HDA chipsets I detected 2 problems with that translation:

1. UniAud?16.sys maintains a list of names of supported sound chips. "HDA Intel" is part is of that list. Unfortunately UniAud?32.sys does not report the string "HDA Intel" to UniAud?16.sys, but the name of the codec chip connected to the HDA interface, like "ALC880" in your case or "STAC9221 A1" in my case. So UniAud?16.sys will refuse cooperation.

2. UniAud?16 has 2 built-in strategies to map the MMOS2 required sound sample rates of 5k/8k/11k/16k/22k/32k/44.1k/48kHz onto the sample rates offered by the hardware through UniAud?32.sys. In case the hardware provides only a single sample rate in the range 0..48kHz, then UniAud?16.sys will perform real sample rate conversion in software. In all other cases UniAud?16.sys will simply try to play at the next lower rate offered from the hardware through UniAud?32.sys. For instance with the Sigmatel codec which offers more than one sampling rates, but 44.1kHz is the lowest of them, both UniAud?16.sys strategies will fail, when MMOS2 does its initial test at boot time trying to set the sample rate to 22kHz.

[vladest]

there is 2 possible problems: 1. as you described in p.p.1 of the ticket 2. wrong control names for HDA, which doesnt supprted by uniaud16

I'll investigate both that cases possible it will require to get com-port log from uniaud16

[rlalla@…]

No chance to get com-port log here. This is a "legacy-free" computer with no com-/parallel-/ps2-ports and no expansion slots. Only high level interfaces are present, like usb, firewire and ethernet.

[rlalla@…]

My proposal about so far unsupported HDA mixer names: Keep the list of name present in UniAud?16.sys as it is. Instead I would propose to modify OSS32_QueryDevCaps() in UniAud?32/sound.c, that in case of HDA chipsets not the mixer name alone is copied to pDevCaps->szDeviceName, but the string "HDA Intel" with mixername appended.

[vladest]

there is uniaud16 and uniaud32 hda test on netlabs ftp try it

[rlalla@…]

Recognition of codec name in UniAud?16 now works here.

Setting the sample rate requested by MMOS2 to 22.05kHz still fails. As explained above, the HDA/Sigmatel hardware supports sample rates 44.1kHz, 48kHz (and higher), but sample rate conversion will be only performed by UniAud?16 in case the hardware provides one single sample rate.

[rlalla@…]

In general sound through MMOS2 is working now, both DART and WaveAudio?. But it is not very reliable yet. Sometimes sound playback does not start, sometimes applications hang while playing sound. DART seems to be more troublesome than WaveAudio?.

Looking into the ALSA32$ log files, I see many error messages (4 types of):

OSS32_WaveAddBuffer failed on partial transfer fa1ba700 2304; ret = -32

requested size [15584] less then available [<NULL>]

OSS32_WaveAddBuffer buffer overrun: size 16384, ret -32, trans 0, prev sz 8416 per sz 2816 total 70368

<3>hda_intel: azx_get_response timeout, switching to single_cmd mode...

[rlalla@…]

Error messages in ALSA32$ log file with Oct-16 build:

 ...
Hardware parameters: sample rate 44100, data type 2, channels 2, period size 704, periods 22
Device is not in proper state: 1. Calling prepare
OSS32_WaveSetHwParams return 0 after SNDRV_PCM_IOCTL_SW_PARAMS ioctl, streamid f0ed0a48
<3>hda_intel: azx_get_response timeout, switching to single_cmd mode...
OSS32_WaveAddBuffer buffer overrun: size 16384, ret -32, trans 0, prev sz 528 per sz 2816 total 0
OSS32_WaveAddBuffer failed on partial transfer fa1ba700 2304; ret = -32
requested size [16384] less then available [<NULL>]
requested size [16384] less then available [<NULL>]
requested size [16384] less then available [<NULL>]
OSS32_WaveAddBuffer failed on partial transfer fa1ba700 2304; ret = -32
 ...

[psmedley]

What is the current status of this? Have latest 2007 builds of uniaud helped at all?

[yoda]

Replying to psmedley:

What is the current status of this? Have latest 2007 builds of uniaud helped at all?

Not for my HDA. Problem with HDA seems to be different for different versions of HDA and Codec - so this bug can be confusing by its general HDA subject. I'll create new bugs for my specific HDA.

[gentux2]

Replying to guest:

Dmitry Froloff reminds that it's difficult implement normal support for this adapter because of kernel threads requirement. (Eugene Gorbunoff, eCo Software)

I opened ticket:78 to document and discuss kernel threads. I do not believe it is actually required for normal support.

[yoda]

Open tickets for specific HDA problems. We now all know of the generic ones.