Intel 82801g(ICH7) I O Controller Hub AC97 Audio
Heinz Francis
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.
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.
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 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.
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.
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:
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. ?
Oh yeah, I should have mentioned that in my opening post: the player is currently hard-coded to play back every WAV file at 44100kHz, regardless of the file's actual intended playback frequency. The file name PCM1622S.WAV implies a 16-bit 22kHz stereo file. Such a file would be played back at twice the speed. So it might just be as intended.
A good next step for improvement might be to have the tool analyze the file for a possible WAVE_FORMAT_EXTENSIBLE header to see if there is a specific frequency that the file is intended to be played at, and if so, configure the sound device to play back the digital audio at that rate. I'll try to have a go at that.
Okay, that one is interesting, especially since the original author of the tool had only an ICH2-based motherboard to develop and test the code with, and therefore ICH2 was the only variant that he had initially enabled in the code. This might be an example of different AC'97 codecs being wired up to the controller differently, requiring adjustment to the volume setting code.
Could you check in Win9x (or whatever more modern OS you might have installed on these systems) exactly what driver (from which vendor and such) you have installed, and what sound devices are shown in the Device Manager?
Espeak apparently synthesizes the speech at 22kHz and I found no obvious way to have it render the resulting audio at 44.1kHz instead, so I converted it with ffmpeg instead. I'll also attach the results to this message.
By the way, when you tried it with the Compaq TR100 board, did you get the idea that it was actually playing back the file, but just with muted audio? Did it behave like it was playing, so a delay before seeing the DOS prompt that took about as long as it did to play the file on he other two machines? Or did it hang or do other weird stuff, like immediately quitting?
[...]
Oh yeah, I should have mentioned that in my opening post: the player is currently hard-coded to play back every WAV file at 44100kHz, regardless of the file's actual intended playback frequency. The file name PCM1622S.WAV implies a 16-bit 22kHz stereo file. Such a file would be played back at twice the speed. So it might just be as intended.
Hmmm, now that you mention it, and after I've taken another look at the code, you're right, it does seem to make at least an attempt to read the sample rate from the WAV file, if available. But apparently not all WAV files include sample rate information in their metadata. So if it can't find it, I guess it somehow either falls back to 44100kHz, or it happens to be the default in the device and it remains unchanged.
I guess I got confused by the comment line "enable codec, unmute stuff, set output rate to 44.1" in codec.asm, as well as the hard-coded define "SAMPLE_RATE_441khz" in codec.inc. But that constant isn't used anywhere in the code, at least not anymore. So apparently both that comment line and the constant are remnants of an earlier version in which the sample playback rate was still hard-coded.
So apparently the raw audio output from espeak (before I ran it to ffmpeg to resample it) didn't contain the necessary WAV metadata for the tool to detect the correct sample rate. But I'll have to retry that to make sure.
Cool! If you install Win98SE, one other thing that you'll be able to try is to unmute the sound device and set its volume in Windows and then exit to DOS (which you could still do in Win9x OSes, I believe) and then run the player, to see if it's indeed just the unmuting and volume changing part that's not (yet) working.
I think I read somewhere that the AC'97 standard only mandates 48kHz and that everything else is optional, so maybe the specific CODEC chip in question does not even support other sample rates?
Just guessing here.
Hmmm, okay, that's interesting. In that case, it increasingly begins to look like the sample rate configuration part of the code isn't working properly either, or that it perhaps doesn't work the same on every combination of ICH revision and AC'97 codec. As a first next step, I'll let the player output the sample rate that it detected from the file, to make sure if at least that part is working.
These files are quite a bit longer, it also lets me answer your other question: on the ICH2, still no sound, however the system is busy for as long as if it was playing - so it probably is the volume thing.
Edit2: oh boy, forgot how much fun Win98SE could be, particularly on non-standard hardware. After installing Intel chipset drivers everything started conflicting with everything. Removing NIC and disabling USB in BIOS at least got me to the point of having a working desktop (in 16 colours, as the Rage 128 Pro drivers refuse to recognise the Rage 128 Pro installed). Turns out the regular AD1885 drivers also can't do anything with this board, so I need to find the Compaq specific driver somewhere... will do so sooner or later, but not tonight.
I think my next step is to have the player display the sub-device-ID (or whas it the device-sub-id) of the detected sound device, since I can cross-reference those with the device-specific quirks in the Linux and FreeBSD drivers for ICH southbridges and compatible chipsets.
No worries - actually I just received a new Tualatin CPU for this board and was running into limitations of not having a Win98SE box, so it was on my to-do list anyway. Have now found the original Compaq softpaq for the Presario 5000 system it came from (and a Dell OEM driver for the low-profile Rage128Pro that might work), will try them when I have time.
My goal is to write an open source VBE/AI driver for this family of audio devices. VBE/AI in an audio-specific extension of the VESA VBE specification. It was meant as a sound card API and hardware abstraction layer for DOS applications and games. Unfortunately, this extension to the VBE standard wasn't released until 1994, by the time which it was too late to gain any traction in the DOS game industry.
05f2edc126