Custom Query (242 matches)

Ticket #41 mentions that ALSA's HDA code makes use of kernel threads. This ticket is to document what is known about this.

There are two sides to the equation: understanding Linux's kernel thread implementation, and how to actually spawn the threads in OS/2.

Linux's thread implementation is self-documented by its source code. I myself was not able to make sufficient sense of it in the time I had to study it.

Knut and Pavel were generous enough to explain OS/2's kernel threads and how to make use of them, which I will summarize below.

However, it appears to me that this is not a requirement for the driver to work properly. Before going to the effort it should be determined why threads are used and whether the benefit of them is worth the trouble.

In ALSA, the "alsa-kernel" directory is compiled "as-is" only when compiling the Linux kernel. When ALSA is compiled standalone, it uses an alternate source tree located outside the alsa-kernel directory. The directory and filenames match those in alsa-kernel, but the majority of them contain nothing more than "#include ../alsa-kernel/myself.c" where myself.c is the name of the very file. Others have instead a patch, to make them different.

In the case of hda_codec.c, the only place where kernel threads are used, this patch removes the use of kernel threads when built against kernels older than 2.6.0. This would seem to be proof that kernel threads are not a requirement for proper HDA support. This is true in ALSA 1.0.14 through 1.0.15rc2. ALSA 1.0.13 and earlier do not use kernel threads at all.

If the benefit is found to justify the work and someone is inclined, the following is what I know about threading on OS/2.

OS/2's kernel threads can be accessed using the VDH (Virtual Driver) interface using VDHCreateThread(). I am attaching the example C code that Pavel provided.

Pavel indicated that use of this API may trap on SMP kernels, so does not advise it, though Knut suggested that it should work fine if it is done properly and carefully.

The alternate approach that Pavel advises is to use OS/2's userspace threading through a userspace daemon that is executed from the config.sys. This, he says, is how ACPI does it and it works well with all OS/2 kernels including SMP.

For memory savings and other reasons, Uniaud32 should be made to load only the support for installed devices.

Two options are proposed to achieve this. We need to investigate which would be the most prudent.

1. Implement the module loader from Linux, so UNIAUD32.SYS loads module objects from disk the way Linux does.

2. Change the build to generate individual .SYS drivers like UNIAUD32.SYS now, each only for a single device. The correct ones are then added to CONFIG.SYS.

I installed RC1 of UniAudio? 1.1.4. The driver works well on the notebook. I have sound in the WPS, and also with Z!. Also, when I remove the AC power and run on battery, the sound is OK! (the CPU throttles down automatically)

When I do a suspend/resume with the Thinpad, there is no sound afterwards. When I try to play an MP3 with Z!, Z! "hangs". (I can kill it) Also, no sound in the WPS.

What do you need to fix that ?

Chipset: Vendor 1013h Device 6003h Crystal CS4610/14/22/24/30 SoundFusion? PCI Audio Accelerator eCS 1.1, German