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.

ALSA modules can accept kernel parameters on the modprobe commandline: e.g.:

modprobe snd-hda-intel model=medion

This can help to enable hardware-specific quirks necessary for proper functioning, in some cases, especially with support for the newest hardware. Uniaud should accept and utilize these same parameters in the same way from the CONFIG.SYS, perhaps:

DEVICE=C:\MMOS2\UNIAUD32.SYS model=medion

or:

DEVICE=C:\MMOS2\UNIAUD32.SYS /K:model=medion

The 64-bit math bug in OW1.6 discovered in ticket #52 prevents Uniaud32 from working properly in many cases. To avoid variable results, the build process should check the version of OpenWatcom being used to build and fail with an error if <= 1.6.