OSDev.org

I'm having problems with yet another device in VMware, and I'm not sure what I'm missing. (Why don't things just "work"...!)

The PCI BAR0 for the Ensoniq AudioPCI 97 (actually, it's a SoundBlaster CT5880, to be specific) in VMware is giving me back 0x2081 (I/O Port 0x2080). I've verified this is correct by running WinXP and checking the device manager... same port number.

But the PCI command and status registers don't match the hard coded values in the Ensoniq spec sheets, nor do the I/O registers match their reset values. In both cases, I'm getting bits set that should be hard-wired clear, and bits clear that should be hard-wired set. I'm getting all zeros for all I/O ports, except offset 0x10 (Sample Rate Converter) which toggles between zero and 65536, and 0x1C (not mentioned in the spec sheet at all), which returns 0x28 (or sometimes 65534).

All of the other ports return zero, and simply store and return any value that I set them to. The soundblaster ports 0x220 and 0x240 both return -1, so it doesn't look like it is emulating a sound blaster, either (which it should). I'm reading 32-bits at a time into EAX.

Sound is working great in Windows XP, so there's got to be something that I'm missing. Anyone have any experience with this sound card?

Thanks, guys.

EDIT: I found code in the Linux driver source that both sets the Sample Rate Converter register to 0x10000, and checks later for that same value, so that would explain the 65536 that I'm seeing. So maybe all of the other I/O registers are... not... implemented?

EDIT2: I figured out how to get access to the AC97 registers, now. The CODEC register (0x14) allows you to read from and write to the AC97 registers, but you have to set bit 23 in order to read anything. Making progress... slowly.

SpyderTL wrote:I'm having problems with yet another device in VMware, and I'm not sure what I'm missing.

May be it worth to ask about other devices implementation quirks in VMWare? I mean the specific device you are asking for may be not known by most of osdev members, but the same kind of problems with other devices may be well known, like some data-sheet incompatible register values or some internal mechanics of the VMWare itself.

Yeah, it looks like most of the device registers are ignored. I think they just implemented the bare minimum registers to get Windows to run properly.

I saw a little of that in VirtualBox, but nothing like this. They at least hard coded the values that were supposed to be hard coded...

Just a quick question about AC 97. The Ensoniq AudioPCI documentation states that it is AC 97 compliant. But I actually created the AC 97 wiki page, and the I/O registers don't look anything like the ones on the AC 97 device I was documenting back then. (I was looking at the VirtualBox AC97 sound card)

So I'm starting to think that "AC97" simply defines a set of registers that provide information about speakers and audio formats, but doesn't actually define how to play audio on an AC 97 device. Each device still has its own API that you must implement if you actually want to play an audio clip.

If so, I'll need to go back and update the wiki. Is it more accurate to say that both Intel ICH and Ensoniq AudioPCI implement the registers defined by AC 97, but the procedure for accessing those registers is different?

I suspect that this due to some confusion about the meaning of "AC'97"

Here, thanks to Wikipedia is a picture of an Esoniq AudioPCI 97:


Observe that on that card are two major chips - one is the AudioPCI chip itself, and the other (made by AKM) is the codec. AC'97 doesn't specify any programming interface for software (After all, from Intel's perspective this was entirely related to motherboard onboard sound and they don't care about competitor's motherboards). What AC'97 specifies is a protocol for connecting audio interfaces to a codec, and the capabilities of that codec. Hence the name - Audio Codec 97. The primary idea was to standardize an interface that Intel could implement on their chipsets, and that codec vendors could implement on their codecs, to make motherboard onboard sound as cheap and simple as possible, without major supporting chips.

AC'97 does define some programmer exposed registers, yes, implemented by the codec. But it doesn't define a full programming interface - this can be considered similar to the defined MAC registers for Ethernet. In fact, there are large parallels here - in both the case of an AC97 codec and a MAC, you have an interface which converts between signals the host can handle with the outside signalling format (in the case of AC97, analog and maybe S/PDIF)

So the AudioPCI 97 is an AC'97 device in the same way as your average ethernet controller implements an interface like MII to talk to a MAC - this is the interface used to talk to the analog components. The codec in the above picture? Yep, that uses AC97

(Side note: The other purpose of AC97 was to support technologies like the AMR - Audio and Modem riser - and CNR - Communications and Networking riser - which were designed to make motherboards cheaper by moving the analog/high frequency components which must be certified onto a separate board. As you might guess from the absence of them from any modern machine, they were unsuccessful because (a) modems were almost obsolete soon after they came out, (b) AMR/CNR modems were less compatible than PCI modems and so ended up not any cheaper, (c) AMR/CNR could only support softmodems, and (d) codecs came down in price, and (e) very soon onboard ethernet and audio became so essential as to defeat the purpose)

So as far as the OS is concerned (or the driver), an AC 97 standard device really doesn't help much, since the code to access the AC 97 functionality will be different for each device. And the code to play or record audio isn't actually defined by the AC 97 standard.

Would you say that this is a similar relationship to the one between ATAPI and SCSI?

How about HD Audio? Is it more of a reference device standard, or is it just another pass through standard protocol that has multiple interfaces/implementations?

Edit: it looks like HD Audio is more like a reference device than a protocol, since the specifications actually include "controller" registers.

So, here's where I'm at with the Ensoniq AudioPCI... The spec sheet does not describe which registers should be set to which values, and in which order. So, I'm using the Linux es1371 driver source code, and the OSS source code to find my way around this sound card.

There is the "base" set of registers, immediately available to the CPU at the I/O address found in the PCI BAR0 register. Then there are additional AC97 registers that are available using the CODEC register to read/write to the AC97 registers. Then there are even more "Sample Rate Converter" registers that are accessed with the SRC register.

The base registers are pretty well documented, bit-by-bit in the spec sheet, and the AC97 registers are documented in the Intel AC97 documentation. But the SRC registers are hardly mentioned at all. I can see that they are being used by the Linux and OSS drivers, and from what I can tell, the SRC registers are responsible for setting up the sample rate for the audio data, but the values are spread across 4 different registers, and the driver source code calculates the values using several hard-coded values that don't make a whole lot of sense.
Does anyone know what is going on here, and does anyone have any documentation on these fields in this SRC register set?

I've tried setting these fields up to play audio starting from physical address 0, but I'm not getting any audio output at all. I just want to hear some noise.

SpyderTL wrote:and the driver source code calculates the values using several hard-coded values that don't make a whole lot of sense.

Code: Select all

frequency = ((rate << 15) + 1500) / 3000

It seems that the driver just assumes that the frequency should be roughly equal to 10 rates. It close to byte per sample (but resulting frequency is less than maximum possible for the bit rate) or to 16 bit per sample (but the frequency is more than possible). The latter case is closer to something meaningful and gives a rough value of the resulting frequency.

So, I've been working on trying to get this to work again. I've spent a few days on it, and I've made some progress, but still no audio in VMWare.

Right now, I'm doing the following (in order):

• Warm-Reset the AC97 codec (BAR0+0, set bit 14 and then clear it)
• Reset the AC97 codec register (Write 0 to AC97 Codec register 0, using BAR0+14h) (This SHOULD set all of the AC97 codec registers -- volume, gain, etc. -- to their default values, but it does not, at least in VMWare.)
• Set the Master Volume AC97 Codec register (Write 0 to AC97 Codec register 0x02, using BAR0+14h) (This does work as reading the value back returns the same value.)
• Set the PCM Volume AC97 Codec register (Write 0x808 to AC97 Codec register 0x18, using BAR0+14h) (This also seems to work.)
• Disable the Sample Rate Converter (Write 0x400000 to I/O register BAR0+0x10)
• Set the sample rate to 44100 in SRC registers 0x74-0x77 using I/O register BAR0+10h. (I have hand calculated these values using the OSS ES1731 driver source code, but I have no idea what they do, or if they are right or not. They are not documented in the ES1371 spec sheet.)
• Set the PCM volume SRC register 0x7e to 0x1000. (I have no idea what this value should be, as it is not documented at all in the spec sheet. I've just tried several different values.)
• Enable Sample Rate Converter (Write 0 to I/O register BAR0+0x10)
• Set memory page to 0x0C (Write 0x0C to I/O register BAR0+0x0C)
• Set audio buffer address (Write 0x00001000 to I/O register BAR0+0x38) (Just trying to get noise, at the moment. Using DAC2.)
• Set buffer size (Write 0xFFFF to I/O register BAR0+0x3C)
• Set sample count and remaining sample count (Write 0x7FFF7FFF to I/O register BAR0+0x28)
• Set format to 16-bit stereo (Write 0x0020020C to I/O register BAR0+0x20)
• Enable DAC2 (Write 0 to I/O register BAR0+0x00, and then write 0x20)

A few questions...

a) Does anyone know if I am missing any registers?
b) Should I be using DAC1 or DAC2? I've tried both, and neither work, but I've read that DAC1 is supposed to be used for wavetable synth.
c) Does anyone know what the SRC registers should be set to? I can't find any information on them anywhere.
d) The SRC I/O register (0x10) has a bit (bit 16) that toggles from a 1 to a 0 and back every time I read from it. The spec sheet says that this bit is Reserved, but the Linux OSS driver source code specifically sets and reads this register as a "busy" flag before accessing the SRC registers. So, I imagine VMWare put this toggle in to "trick" the Linux driver into working, but I'm still not sure why it's there, or what it's doing, or where the Linux source code came up with that bit to use as a Busy flag. The spec sheet that I have (ES1731) says that the Busy flag is actually bit 23, which is not toggled, and is never checked by the Linux OSS driver. Does anyone know what is going on with this bit?

The audio seems to work fairly well running Windows XP under VMWare, so I know it's possible to get it to work. There is even a little "activity" light that lights up when audio is playing in WinXP, which never lights up for me when setting all of the registers above, so I'm guessing I'm either missing a register, or I'm setting one of these values above incorrectly.

Does anyone happen to be an expert in old DOS era Ensoniq cards?

AWWWW YEAH! Finally got sound.

It's always in the last place you look...

The PCI Command register had Bus Master turned off for this device. Seriously, VMWare? WTF!?

In any case, I now have noise playing from VMWare. Next step is playing a sine wave, then it's CD Audio.

Shouldn't take long now. I'll take a few minutes and update the wiki with the info I've gathered so far.

Alright, now I've run into a new problem. I can play some audio data, but it looks like the first time I get an interrupt from the ES1371, the whole system locks up in an infinite interrupt loop, and the audio stops.

The only way I can get the audio to keep playing (in a loop) is to disable interrupts on the CPU (CLI) before enabling the DAC2 bit. It also looks like it may be starting to play audio from the end of the buffer, and immediately calling an interrupt because the buffer has been played, because if I turn off looping, nothing plays at all.

I know that no one here can help me with this, but I thought that I'd post an update, anyway. I'm just using the forum as a journal so that I can vent some frustration. Hopefully that's not against the rules.

Huh! I've got stuck with the ensoniq driver just for the similar reason (infinite loop of some noise from the buffer) about a 2 years ago. Hm... maybe it's time to to do something with it.

Were you using VMWare, or do you actually have a machine with an Ensoniq sound card? (I'm assuming you were using VMWare...)

I was using Qemu..

Okay, I think the problem that I'm having is that I'm getting an IRQ 5 interrupt even though I have DAC2 interrupts turned off on the ES1371 device. (I am writing 0x0020000c to BAR0+0x20)

Since I was planning on just polling the interrupt flag on the device, I don't have any custom code written for the IRQ 5 handler. I'm just using my default handler, which acknowledges the PIC, and does an IRET. So the DAC2 interrupt on the ES1371 never gets acknowledged and it immediately raises another IRQ5, and gives the CPU no opportunity to run my code that checks for the interrupt flag.

So, I'm in the process of changing my code to replace the default interrupt handler while audio is being played, but in the long term, I have plans for a whole interrupt event subscription framework.

I seriously doubt that this would be an issue on real hardware, as I doubt that a real ES1371 will trigger IRQs even when they are disabled by the driver...

I'll let you guys know how it goes.

EDIT: I think I've got it working, but I'll need to do some more testing to be sure. I think it's stable enough to move on to something else, which is really all I wanted

I'll update the Wiki, as well.