Custom Query (242 matches)

If I try using UnimixPM to control sound, lots of the controls are disabled, and can't be used. Using Unimix, a lot more controls seems to be available. Something in the interface must be wrong.

Attached unimix.log and a picture of UnimixPM layout window.

In the makefile.os2's of the drivers, isa, and pci directories under alsa-kernel, there are driver source files listed that have been commented out. Edits have been made at some point to those source files, so a port was at least begun. AFAICT there does not appear to be support for these in the other places necessary to make them work even if they were not commented out of the makefiles.

An attempt to compile pci/ice1712 after the merge to 0.9.0rc4 failed with errors.

The problems with this scenario are:

1. Hardware that could be supported by Uniaud is not.

2. Uniaud is now tailored to work only with a few driver files with significant modifications. Tailoring it instead to work with a greater number of ALSA drivers with fewer modifications would reduce the work required to add support for new hardware, and reduce the chances for bugs peculiar to each hardware configuration.

3. The present AlsaResync is merging these source files without any testing, which leaves room for error and reduces or nullifies the benefit of the work.

My proposed action at this point is to test whether these files compile successfully before the resync, and whether that has been broken by any stage of the resync, fixing as needed. Even though this does not in itself enable support for the hardware, it preserves that potential, reduces merge error, and also provides more clues about what in Uniaud outside of alsa-kernel might need done to improve general compatibility with ALSA.

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.