How to play sound Intel HD Audio?

[Klakap]

Thank for reply! I change code, but forever cycle is still here. I test it in QEMU.

[DavidCooper]

Code: Select all

(10) I create a value in AX which has AL=0 and AH=80h, then push it onto the stack. (In other words, I set bit-15 and reset the rest.)

...

(17) I recover (to EAX) the value on the stack which was put there in step (10). I then post that value to ESI+58h to set the RIRB write-pointer to the right place for the replies from the codec.

Have you accidentally deleted the line that does step (17)? You certainly need it to reset the RIRB write-pointer. I currently do that by sending 0x8000 to port 58h (though in doing so I'm writing zeros to seven reserved bits, so technically I should be reading the port first, then setting bit-15 to 1 and bits 0 to 7 to zero before sending the result back).

If you need to do further debugging experiments, it could be worth reading 4Ah to see if CORB has sent the instruction out - that would tell us if one of the DMA engines is working. I've never run my code on an emulator, and because they can sometimes be more fussy than most real hardware, there may be something else needing to be fixed before your code works on it, so study the specification and try to guess what extra things QEMU might require you to do.

[Klakap]

Thank for reply. I try my code in Virtualbox and QEMU, but forever cycle is here. I try it on my computer(it have Intel HD Audio card) but all ports have 0xFF or 0xFFFF or 0xFFFFFFFF value, so all whiles are forever! Please, where can be error?

[nullplan]

FF is the open bus value, i.e. what you get when there is just nothing there. I guess while your computer has an HDA card, your VMs do not. Have you found an HDA card on their PCI busses?

[Klakap]

Yes, on PCI is Intel HD Audio card.

[DavidCooper]

I don't see how your code can be reaching the "forever cycle" at the end if all the ports are 0xFF...s. When you reset the CORB read pointer you shouldn't be able to move on from there until you've read back a zero in bit-15, so that's the place where you should have got stuck in a forever cycle. I had assumed that because you were getting past that point that you had found all the right ports to work with. Anyway, you must have a broken installation of QEMU which hasn't been set up correctly for your machine. I don't know how to put that right, but if your OS is stable enough you should be able to work directly on real hardware and use the real HDA ports. That's really inconvenient though unless your OS is sufficiently advanced to allow you to write drivers within the OS so that you can modify & test them repeatedly without having to reboot, so you should maybe build that functionality into your OS first.

[Klakap]

0xFF ports is on real hardware, no in QEMU. I dont know why is forever cycle here, but it is on more computers what have installed QEMU.

[DavidCooper]

Let's go back a step then. How are you identifying HDA as existing on the machine and how are you finding the base address for its ports? Can I see your code for doing that.

[Klakap]

https://github.com/Klaykap/LightningOS/ ... vers/pci.c

Yes, I am not 100% from specification besause I am identify Intel HD Audio by class 0x04 subclass 0x03, but operation system is using hda_driver for sound card, so I think that sound card is compatibility with Intel HD Audio.

[DavidCooper]

Does your code allow you to collect the details for more than one of the same kind of device? I may well be misreading it, but it appears that if there are multiple devices of the same type, the last one found will override the details of the previous one each time. It's unlikely, but there may be some fake devices in there that provide vendor and device IDs but which have disabled functionality. (RDOS used to report finding such fake devices in some of the machines he tested.)

If you're sure that there's only one device there that can be the hda one that you're looking for, then I'd like to see all the numbers that you're getting from it for the 256 bytes in the PCI space. I'd particularly like to see the byte at 40h which may need to be set to 1 to switch the hda ports in.

[johnsa]

Hi,

I've just recently finished my own HDA driver, I have it working on all VMs and the 6 real machines I have access to. I'm busy trying to get it to work on my Mac, which is posing some challenges but I'll go into that later.

Firstly, one thing I've noticed as a potential issue which I've not seen mentioned in any of the OSS source or spec that caused me some grief was that in the PCI configuration space I needed to ensure that not only was bus master enabled but that memory space access was too. On some real machines without doing that any attempts to read/write to the HDA regs just returns garbage. I've also done all the other vendor specific changes regarding snoop/no snoop and traffic quality select etc.

A good test is to firstly get all the global caps and stream counts etc as well as corb/rirb sizes.. that way you can sanity check that you're getting the correct values.
Also ensuring that you configure the MMIO correctly based on the BAR being 64bit capable.

[DavidCooper]

Hi johnsa,

Good to have your input on this. I was lucky with the PCI configuration space part of this in that my machines made that easy, but I did worry that it might not be so easy on other machines and on emulators. Whatever you've learned about that from writing your driver, I'd like to get it added to the wiki page to help others, particularly as we have some blind programmers writing operating systems who could benefit greatly from having the path to getting audio made more open to them. It's as important as a screen.

[johnsa]

I couldn't agree more. One thing that really appealed to me about writing an audio driver, apart from the fact that it led to some nostalgia of me writing audio replay systems back in the 90's for Amiga/Adlib/SB and GUS was that unlike the immense undertaking a graphics driver is these days its a relatively low barrier to entry to have something really tangible coming out of it within a matter of days. It's hugely rewarding and the reason I think that anyone would enjoy this sort of low-level hardware banging.

I will write up any notes or additions I have to the wiki.
I have to say though I wish all pc hardware had specification documents like the Intel HD Audio one.. it's the best written piece of h/w documentation I've seen for any piece of PC hardware! It reminds me of the days of the Amiga HW reference manuals almost! If Intel wrote similar type of documentation for their GPUs that would be amazing.

So as I was mentioning, I have this working so-far on every PC I have access to, on my Mac however it seems to be slightly different.
The PCI level and basic device/chip reset works. I'm getting back all the global caps which seem valid, 4xSDI , 4xSDO, 64bit capable, 0x400 and 0x800 sizes for the CORB and RIRB buffers. It reports one codec at address 0.
Where it seems to fail on the mac however is that the first command I send to the codec is to get the device and vendor id. The Corb WP I update, I've checked the Corb RP and can confirm the command has been read by the controller however
unlike all my other machines the RIRB response never comes.

So I don't know what codec the mac is using, the HDA controller is a regular intel one with vendor id: 0x8086 and device id: 0x8cA0

[DavidCooper]

Do the optional registers 60h and 64h exist on the Mac's hda? If so, you should try using them to speak to the codec directly first as it should bypass a lot of potential complications. If they exist and work correctly, it would be possible for a driver to do everything using them instead of CORB and RIRB, and that might be a way to get some troublesome machines to work, assuming there aren't similar difficulties with the other dma engines.

One of the things I found was that using directly adjacent buffers could trip up the dma engines and prevent one from working even though there was no overlap and the buffers were correctly aligned, so if you haven't experimented with that it may be worth doing so.

[johnsa]

I've got the corb and rirb buffers each in their own 4kb page separated as I suspected that might be an issue.
I've not tried the immediate command interface, that is a good call.. I'll see if I can get something back from that.

One thing that has occurred to me as well, the approach we've probably all used is a generic widget enumeration, I think in the long term I will keep that as a fall-back, but having dedicated implementations for specific codecs would have some major advantages in being able to deal with codec-specific features/vendor specific widgets for all the processing effects etc that they can potentially support.
I'm also wondering if there might not be cases where specific codecs have initialisation requirements above and beyond the standard spec.
Having a look at : https://www.insanelymac.com/forum/topic ... nt-2453130