OSDev.org

I've done a little research on modern audio chipsets. Seems like virtually every modern computer (at least 3 different computers I have) supports the same standard (Intel High Definition Audio). This means that by writing just one device-driver, audio can be supported on most modern computers. The specification is rather large, and especially the codec part is rather complex, but it also seems like most implementations are simple enough.

I plan to write the base functionality in assembly, and the codec (and the connection diagram) in C.

I have one issue though, and that is support for 64-bit addresses. The HDA specification does describe a 64-bit interface, but it is said to be optional. If the computer has more than 4G (or memory aliased above 4G), it would create a big problem if the controller doesn't support 64-bit physical addresses. Would this be common enough, or could a possible strategy be to not support the audio-controller if the machine has memory above 4G and the controller doesn't support 64-bit?

It is a very common problem, most operating systems implement bounce/double buffers, reserving pools of DMA-'able memory. A lot of people still use 32-bit PCI devices in 64-bit computers.

Some newer Intel and AMD systems include an IOMMU, other architectures having had this for quite awhile now.. x86 world is still playing catch-up.

The HD Audio codec specification is really complicated, with minimal advantages for typical usage (much like ACPI and USB HID). Sure, it is nice to be able to build a complex interconnection diagram of the codec, and be able to control every detail of it, but it is not something that normal usage would benefit from. Rather, typical usage is to activate some jack / fixed speaker, and controlling the volume control. This requires a lot of code to solve on a range of typical HD Audio codecs.

What should be a trivial issue, controlling the built-in speaker in a laptop, is most complex and poorly documented. After inspecting a range of different laptops I think I know how to detect which node is the built-in speaker, but I haven't verified the correctness of this assumption yet.

Anyway, now I can list which nodes represent real inputs and outputs, including the built-in speaker. The next problem is how to activate a path with multiplexers, pins and mixers from the output node to the jack / internal speaker.

I still have trouble with something in the HD Audio & codec driver. The codec link works fine with IRQs on all setups, and the trees look reasonable on all machines. The problem is with streaming the data to the codec and getting some sound output. None of my test machines produce any sound, but at least one of them have a running stream that produce the correct end-of-buffer notifications, while the other 3 just hang waiting for the interrupt. I also know that the stream advances, and the engine is running.

These two machines doesn't produce an interrupt:
Dual core Intel Atom: ALC269 codec, HDA PCI IDs: 8086 27D8,
Dual core AMD Athlon: ALC883 codec, HDA PCI IDs: 1002 4383

This machine has a running stream (with interrupts) but no sound:
Dual core AMD portable: ALC270 codec, HDA PCI IDs: 1002 4383

The strange thing is that the working machine has the same HDA chipset as one of the non-working, and the codecs are almost similar between the two other pairs.

Suggestions as to what might be wrong are welcome.

Seems like the problem with interrupts was related to caching. The in-memory structures were just ordinary pages, and obviously this worked on one machine but not the others. When I set the PCD bit in the page tables for each of the mapping linear addresses, the interrupts work on both machines. Still no sound though.

Issue solved. All my machines now produce sound, although one of them seems to have too much distorsion. It is the same machine that also doesn't report the current DMA position correctly.