First post, by digger
- Rank
- Oldbie
So I dusted off an old yet interesting piece of code I found on the internet, that some of you are probably already familiar with: Jeff Leyda's .wav DOS player for ICH AC'97 audio devices.
It's small, simply written to do one job, very well documented, with well-structured, well-commented and quite understandable assembly code. It's the first example of modern PCI sound programming that I didn't find intimidating.
And most of all: it works! 😀
Long story short, I need people with actual AC'97 sound hardware (Intel southbridges at first, in a later stage perhaps also implementations from other chipset vendors) to test my recent changes to it.
My ultimate goal is to use these sources a basis for a a VBE/AI DOS sound driver for AC'97 sound devices, which could one day perhaps ship with FreeDOS.
Anybody care to help me with this? I mean testing, although code contributions would be absolutely welcome as well!
I've attached a recent build that you can try. If you prefer to build from source, you can find it (including my modifications to it) here: https://github.com/volkertb/ich2player
The code can be built with MASM (Microsoft) or WASM (Open Watcom).
In particular, I'd like to test on the following southbridges:
- 82801AA AC'97 Audio Controller (ICH)
- 82801AB AC'97 Audio Controller (ICH0)
- 82801BA/BAM AC'97 Audio Controller (ICH2)
- 82801CA/CAM AC'97 Audio Controller (ICH3)
- 82801DB/DBL/DBM AC'97 Audio Controller (ICH4)
- 82801EB/ER AC'97 Audio Controller (ICH5)
- 6300ESB AC'97 Audio Controller (ESB)
- 82801FB/FBM/FR/FW/FRW AC'97 Audio Controller (ICH6)
- 82801GB/GBM/GR/GH/GHM AC'97 Audio Controller (ICH7)
- 82440MX AC'97 Audio Controller (440MX, technically not a southbridge)
If you have any systems or laptops with any of these southbridges or chipsets in them, would you care to help me test this?
I'd very much appreciate it. Thank you! 😊
Volunteers with other AC'97 compatible hardware not on this list are welcome too! Let me know what chipset you'll be testing with exactly, though, because I may have to add the vendor and/or device IDs for them to the sources for it to have a chance of working at all.
Oh, and be careful when you specify the `/v` parameter, since that will set the line-out and master output volume of your AC'97 device to the maximum level. If you have another tool to set the volume before running the tool, then it's best to leave the `/v` parameter out. In most cases, your AC'97 device will be muted by default, though, so bear that in mind when you don't hear any audio while testing.
Oh, and Jeff, if you happen to read this as well: thank you for sharing this cool bit of software with the world, along with the sources. It's proven quite educational! I hope you're well, wherever you are.
In more detail:
The original code had only ICH2 (82801BA/BAM) southbridge support enabled, since that was the only hardware (Intel 810 or 815) that he had available to test with at the time.
However, when I added a few lines to enable ICH (82801AA0) support as well, I found that that worked fine in QEMU/KVM and VirtualBox VMs, when I had the AC'97 sound device emulation enabled in both hypervisors.
That made me confident enough to enable support for ICH and ICH0 (which came between the original ICH and the ICH2) as well.
In the comments of the source code, Jeff mentioned that he expected later Intel ICH southbridges to be compatible as well, so I looked up the PCI device IDs of all the later Intel AC'97 devices, going all the way to ICH7, and added "support" for those to the utility as well.
...Or at least I *think* I did. From what I understood in these thread on the Flat Assembler board, configuring the codec properly (unmuting, setting the volume, etc) might not be entirely 100% compatible in later southbridges, such as ICH4:
- https://board.flatassembler.net/topic.php?p=159150
- https://board.flatassembler.net/topic.php?p=159887
So perhaps some tweaks or changes to that part of the source code (specific to certain southbridges and/or certain different brands of codec) might be necessary after all.
I also perused the intel8x0 ALSA Linux kernel driver sources to get some clues, but that is a pretty hefty piece of code. At first glance it did seem that there were a lot of vendor-specific changes, but I was expecting (and kind of hoping) that between devices of the same single vendor (Intel), the compatibility would be mostly 100%. That may have been a naive assumption, though. 😅