HD Audio + Virtualbox

bigbob · Post by **bigbob** » Wed Jan 21, 2015 12:15 pm

Hi,

Currently I am working on the HD-Audio(HDA) driver and I am using VirtualBox(version:4.1.18).
It is useful to discuss/publish the HDA-related features of Virtualbox and I also have a few questions.
It will be a long post.

The stuff I have been using:
- High Definition Audio Specification Revision 1.0a June 17, 2010 (Intel)
- http://wiki.osdev.org/Intel_High_Definition_Audio
- KolibriOS' code
- http://www.pcidatabase.com/search.php?d ... definition
- http://www.pcidatabase.com/vendor_details.php?id=1302

List of PCI-devices in Virtualbox:

Code: Select all

b  d  f  DId  VId  Cl SubCl
00 00 00 1237 8086 06 00	PCI & Memory
00 01 00 7000 8086 06 01	PCI-to-ISA
00 01 01 7111 8086 01 01	IDE Controller
00 02 00 BEEF 80EE 03 00	VB Graphics Adapter
00 03 00 100E 8086 02 00	Pro1000/MT
00 04 00 CAFE 80EE 08 80	VB Guest Service D.
00 05 00 2668 8086 04 03	HD AUDIO (ICH6)  *********
00 06 00 003F 106B 0C 03	SCSI Controller
00 07 00 7113 8086 06 80	Power Mgmt Controller
00 0B 00 265C 8086 0C 03	EHCI Controller
00 0D 00 2829 8086 01 06	AHCI Controller

I have managed to implement the list given by the wiki till step4 (see the data from the codecs below).
I decided not to continue with step5 but first see if I can have a DMA-engine running (or a stream), as it is suggested by the wiki-page.
This is how I start a stream:
stream_reset (I call stream_reset from kernel right after boot):
1. clear RUN-bit and interrupts in SD0CTL (0x80)
2. set reset-bit(bit0) in SD0CTL
3. wait 10 ms
4. check in loop if bit0 is 1 in SD0CTL
5. wait 10 ms
6. clear reset-bit(bit0) in SD0CTL
7. wait 10 ms
8. check in loop if bit0 is 0 in SD0CTL
9. wait 10 ms

Perhaps the 10-ms-delays are not necessary.
I have commands audio_play and audioinfo; audioinfo prints the DMApositions(page 55 in spec) and contents of the controller-registers.
audio_play:
1. clear RUN-bit and interrupts in SD0CTL
2. set stream as output and streamId to 1 in SD0CTL
3. set stream format in SD0FMT to 0x4310 (I have a 11.025KHz, bits16, channelsNum=1; wav(PCM))
4. set LVI to 1
5. set BDL to address BDL_BUFF(0x170000) and set the two entries (LVI is 1):
entry1:
[BDL_BUFF] <-- 0x8F5000 (address of wav(PCM)-data)
[BDL_BUFF+4] <-- 0
[BDL_BUFF+8] <-- 88889 (length of PCM-data)
[BDL_BUFF+12] <-- 0 (no IOC)
entry2:
[BDL_BUFF+16] <-- 0x8F5000 (address of wav(PCM)-data)
[BDL_BUFF+16+4] <-- 0
[BDL_BUFF+16+8] <-- 88889 (length of PCM-data)
[BDL_BUFF+16+12] <-- 0 (no IOC)
6. set DPLBASE to 0x160000, and set bit0 to 1, to have the ctrller to write DMApositions
7. start stream: clear interrupts in SD0CTL and set bit1 to 1.

I use a short wav(PCM) for both entries. I hope it is not the problem.

Calling the command audioinfo prints (data in HEX; register-names from page 25-27 in spec):
DMA positions:
00000000
00000000
00000000
00000000
Registers:
GCAP:4401 VMIN:00 VMAJ:01 OUTPAY:003C INPAY:001D GCTL:00000001 WAKEEN:0000 STATESTS:0001 GSTS:0000 OUTSTRMPAY:00FF INSTRMPAY:00FF INTCTL:00000000
INTSTS:C0000000 WALCLK:0126C13D SSYNC:000000FF CORBLBASE:00140000 CORBUBASE:00000000 CORBWP:0000CORBRP:0000 CORBCTL:02 CORBSTS:00 CORBSIZE:42
RIRBLBASE:00150000 RIRBUBASE:00000000 RIRBWP:0000 RINTCNT:0000 RIRBCTL:02 RIRBSTS:00 RIRBSIZE:42 ICOI: 00000000 ICII:0000000 ICIS:0000
DPIBLBASE:00160001 DPIBUBASE:00000000 SD0CTL:00140002 SD0STS:00 SD0LPIB:00000000 SD0CBL:00000000 SD0LVI:0001 SD0FIFOD:0077 SD0FMT:4310
SD0BDPL:00170000 SD0BDPU:00000000

As it can be seen, SD0CTL is 0x00140002 instead of 0x00180002 because it is not a bidirectional engine, so bit19 is RO and bit18 is also RO set to 1.
The problem is that the DMA-positions are zero.
The audioinfo command prints [DPLBASE+0], [DPLBASE+8], +16, +24 (DPLBASE contains 0x160000).

Questions:
Is my stream-related code correct (or something is missing)?
When should I use the Power-State of the widgets? (page 151 in spec)
Flush(GCTL 0x08; GSTS 0x10) shouldn't be used after starting a stream? (KolibriOS doesn't seem to use it)

Can be useful info (Virtualbox):

Codecs-info:
VenId/DevId: 83847680 (VenId:0x8384, DevId: 0x7680)
RevId: 00103401
FG-NUM: 00010001 (starts from 1 and totalnum is 1)
AFG Node Id: 01
AFG Node widgets: 00000002 0000001A (starts from 2 and there are 1A widgets)

Widget-data (step4 of wiki-page) (data in hex):

Code: Select all

WId WCAPS     PinCaps  InpAmCaps OutpAmCaps    ConnlistLen   KnobCaps   ConfDef ConnlistEntry
; Audio-output
02  000D0C05  0	       0	       0	          0		         0	      0	        0
03  000D0C05  0	       0	       0	          0		         0	      0	        0
04  000D0C05  0	       0	       0	          0		         0	      0	        0
05  000D0C05  0        0	       0	          0		         0	      0	        0
08  00040211  0	       0	       0	          0		         0	      0	        0
1A  00030201  0	       0	       0	          0		         0	      0	        0
; Audio-input
06  001D0541  0	       0	       0	          00000001	   0	      0	        00000017
07  001D0541  0	       0	       0	          00000001	   0	      0	        00000018
09  001D0541  0	       0	       0           00000001	   0	      0	        00000011
; Audio-selector
12  0030010D  0	       0	       00270400    00000007	   0	      0	        0B0F150E
13  0030010D  0	       0	       00270400    00000007	   0	      0	        0B0F150E
17  00300903  0	       0	       0	          00000001	   0	      0	        00000012
18  00300903  0	       0	       0           00000001	   0	      0	        00000013
; Pin-complex
0A  00400181  0000173F 0	       0	          00000001	   0	      02214020  00000002
0B  00400181  00001737 0	       0	          00000001	   0	      11111011  00000004
0C  00400181  00001737 0	       0	          00000001	   0	      11114010  00000003
0D  00400181  00001737 0	       0	          00000001	   0	      02A19050  00000002
0E  00400081  00000034 0	       0	          0		         0	      01013040  0
0F  00400185  00000034 0	       0	          00000001	   0	      10116012  00000005
10  00400301  00000010 0	       0	          00000003	   0	      01481030  00191708
11  00430681  00010024 0	       0	          0		         0	      01C61060  0
15  00400001  00000020 0	       0	          0		         0	      90330070  0
1B  00400301  00000010 0	       0	          00000001	   0	      4000000F  0000001A
; Volume-knob
16  00600000  0	       0	       0	          00000004	   000000FF 0	       05040302
; Beep-gen
14  0070000C  0	       0	       00170303    0		         0	       0	       0
; Vendor-defined
19  00F30201  0	       0	       0	          0		         0	       0	       0

For example: widget with WId=0D is a PinComplex and has CONNLISTLEN=1 and is connected to widget: 2

DavidCooper · Post by **DavidCooper** » Thu Jan 22, 2015 4:01 pm

Have you set up an ADC or DAC? I don't think you'll be able to get a DMA engine running unless it's connected to an active ADC or DAC, but ADCs and DACs can run even if no other widgets have been set up. If that isn't the issue, I'll read all your numbers more carefully and see how they match up with the way I do things.

bigbob · Post by **bigbob** » Thu Jan 22, 2015 4:18 pm

DavidCooper wrote:Have you set up an ADC or DAC? I don't think you'll be able to get a DMA engine running unless it's connected to an active ADC or DAC, but ADCs and DACs can run even if no other widgets have been set up. If that isn't the issue, I'll read all your numbers more carefully and see how they match up with the way I do things.

Thanks for the help, David.
No, I haven't set up (or configured) ADC or DAC. I thought that DMA-engines would work without widgets being set up.
As I understand the specification, the stream should flow on the link (i.e. DMA engine should work) and the unconfigured widgets simply shouldn't care about the stream. However, I can be wrong very easily.
Tomorrow I will try to configure them, and maybe implement all the steps according to the wiki-page before playing with the streams (DMA). Of course, my code can also be wrong and need to be checked again too

DavidCooper · Post by **DavidCooper** » Thu Jan 22, 2015 4:47 pm

I'm puzzled by the numbers. It looks as if none of the DACs work. I'm trying to see if a datasheet for the codec is available, but the vendor ID for the codec doesn't match up with any company. The device ID does match though with SIGMATEL STAC 92XX C-Major HD Audio.

Edit: Correction, the DAC numbers are fine - I was forgetting that they don't have connection numbers to other widgets because other widgets connect to them instead. The datasheet doesn't appear to be available, and similar ones aren't good enough, so no way to cheat, but that's probably a good thing.

bigbob · Post by **bigbob** » Fri Jan 23, 2015 2:10 am

I also identified the codec as SIGMATEL ... . VendorId doesn't match up with anything but probably SigmaTel is the vendor, and the DeviceID part of the VendorID/DeviceID contains both the vendor and the device.

I forgot to add to my initial post this link:
http://forum.osdev.org/viewtopic.php?f=1&t=26644
There are many useful things there.

I believe, setting up the DAC (or all the widgets) will help, so it will work without the datasheet

EDIT:
If I manage to get HDAudio working (to have sound), I will publish here the widget-connections.
But it wouldn't be a problem if somebody else, who already has it, publishes it

---------------------------------------------
FORTH OS: https://sites.google.com/site/forthoperatingsystem/

DavidCooper · Post by **DavidCooper** » Fri Jan 23, 2015 5:10 pm

The numbers that you've already posted here are a great help as you can't find them in datasheets - you normally have to interrogate widgets directly to get at that data, so you're limited to the range of machines you have access to. It's the first time I've seen what happens when there's a volume control widget, so it's been very helpful: the DACs say they have amplifiers and yet when you look for the numbers for the out amp capabilities you get nothing, which I wasn't expecting, but it's because the volume control handles it instead.

bigbob · Post by **bigbob** » Sat Jan 24, 2015 2:57 am

I also believe, that discussing this is useful. One can rule out widget-connections/configurations if his/her OS doesn't provide sound with Virtualbox, if the widgets-connections are correct for sure.

Both your wiki-page (steps 4-7) and KolibriOS find the Speakers, Jacks first and then try to find the path back to the DACs.
This is how KolibriOS does it (parse_output function is in hda_generic.inc)

Code: Select all

parse_output:   //look for the output Pin-widget
  calls parse_output_jack(LINEOUT)
  if LINEOUT not found:
    calls parse_output_jack(SPEAKER)
  calls parse_output_jack(HPOUT)
  if no LINEOUT or HPOUT found:
    calls parse_output_jack(-1)  //choose first output-pin
end

Code: Select all

parse_output_jack: (input-param: jack_type)
  checks if widget is PIN, if not: skip
  PinCaps & OUTPUTCAPABLE ?, if not: skip
  get portconn of ConfigDef (bits 31:30)
  if unconnected (01b) : skip
  if jack_type is not the type-in-ConfigDef: skip
  skip SPDIF (WidgetCaps: bit9)
  calls enable_pin_sense //to enable UnSolicited events
  calls parse_output_path for DAC0 or DAC1, and returns 1 if DAC found, 0 otherwise
  calls unmute_output //unmutes the Pin-output
  sets Pin-Out enable //if PinWindget is HP-drive capable then enables head-phone(HP): sets bit7 of PinWidCtrl; Out enable: set bit6 of PinWidCtrl (707h)
end

Code: Select all

//parses the output-path recusively, till it finds a DAC (0:notfnd, 1:fnd, neg:err) (Input: NodeID, DAC-Idx)
parse_output_path: 
  recursively searches for DAC, unmutes output, selects input-connection. Skips widget if (WCaps & DIGITAL)
end

unmute_output is a long function, it is better to understand it from the source.

The wiki-page suggests using default-association:sequence, if no if no Speakers show up in bits 31:30.
Probably KolibriOS does something similar when calls parse_output_jack(-1).

Some time ago I read that you, David managed to have voice-recognition in your OS (with HD Audio), but I can't find the topic on osdev.
I am almost sure it was on osdev. Voice-recognition sounds wonderful!

There are a few things that are not completely clear for me in the code of KolibriOS (e.g. why it parses for DAC0 or DAC1, maybe they have different capabilities, I think finding any DAC from the Speaker is fine), but I will implement my driver accordingly.

--------------------------------------
https://sites.google.com/site/forthoperatingsystem/

DavidCooper · Post by **DavidCooper** » Sat Jan 24, 2015 3:14 pm

bigbob wrote:Both your wiki-page (steps 4-7) and KolibriOS find the Speakers, Jacks first and then try to find the path back to the DACs.

I'm not sure it really matters which way you do it, but it will save a fraction of a second of processing time as you can ignore all paths that involve pin widgets that have nothing connected to them. I haven't looked at the code of KolibriOS and still haven't tackled the stage of the process where you find paths through the widgets - I cheated by using the datasheet for the codec in my machine and wrote machine-specific code to link everything up so that I could get on with attempting to do work on speech recognition instead.

Some time ago I read that you, David managed to have voice-recognition in your OS (with HD Audio), but I can't find the topic on osdev.
I am almost sure it was on osdev. Voice-recognition sounds wonderful!

Like most of my work, it's still far from finished - I keep starting on new things and then rotate through all the other unfinished things I'm trying to work on at the same time, so they all creep along towards completion without ever getting there. My repetitive strain injury (RSI) problems eventually eased off enough for me to put speech recognition on the shelf for a time, but I did get manage to write code to separate all the component frequencies in a sound. The photo shows the 8 vowels oo, oh, aw, ah, a (as in "cat"), e (as in "met"), ay and ee (all collected into my OS using a microphone plugged into the microphone socket and using my own HDA code). It does not use FFT, but simply adds up areas under/over the graph by slicing it up at different frequencies to determine how strong the sounds are at each frequency. I found a way of slashing the number of additions required to the point that it can be done in real time as the sound comes in, so there is simply a running total kept of the area (which goes up and down from a positive value to an equivalent nevative one) while at regular intervals (different intervals for different frequencies) frequency variables are updated by adding the change in area since the last time they were updated - these build up to large scores if there is a resonance at that frequency, but otherwise cancel out and produce only a little noise. I don't know how clean the results are compared with FFT, but you can see clear differences between different speech sounds on the screen. I can't get the camera to expose the picture of the screen properly, so it looks a lot more noisy than it does in real life. Unfortunately it's very hard to write code that can actually distinguish reliably between different speech sounds though, because they're always a little different every time you say them, so it takes up a lot of time doing experiments that usually end up not working. Speaking at a different pitch changes all the rules too, so you have to work out which parts of what you're seeing aren't affected by the pitch of the base note and try to base your code on those, avoiding any of the aspects that keep changing. I will continue to work on this when I can find the time, but it is a low priority at the moment. It would be much easier just to write a whistle code language and to speak to the machine that way, using different pairs or sets of three notes to trigger virtual key presses, so that's what I'll do if the RSI problems return.

The wiki-page suggests using default-association:sequence, if no if no Speakers show up in bits 31:30.
Probably KolibriOS does something similar when calls parse_output_jack(-1).

The Wiki suggests that because of Asper's advice, so it effectively comes from KolibriOS.

There are a few things that are not completely clear for me in the code of KolibriOS (e.g. why it parses for DAC0 or DAC1, maybe they have different capabilities, I think finding any DAC from the Speaker is fine), but I will implement my driver accordingly.

It probably is fine just to use the first DAC that you find a route to, but if you ever need to do something more than mere stereo, you may then find that you're forced by available connection options to use specific DACs for specific purposes. On my machine there are three DACs. The middle one cannot connect to anything, but the datasheet shows that on other machines it is used for surround sound. The third DAC allows me to put sound out through the microphone jack, or I can use it to put sound out through the h/p jack while playing something different from the speakers, but only the first DAC can connect to the speakers. If I want to play the same sound through speakers and the h/p jack at the same time, the first DAC can be linked to both. Other machines may work very differently though, and because you don't want to have to switch DAC every time you plug headphones in or out, you want to be sure you're using a DAC that can be linked up to both, so that means it isn't a good idea just to use the first DAC that you find a link to from the speakers without checking that it can also link to the h/p jack.

bigbob · Post by **bigbob** » Sun Jan 25, 2015 3:54 am

I always take a look at other people's code, not only does it give me good ideas, but frequently I couldn't implement a working code just by reading the specs. So, I cheat and you didn't

DACs: now I understand it, thanks.

VR: I always kept postponing implementing HD-Audio, but I experimented with FFT with python (modules: numpy, pylab, matplotlib.plyplot) and read books on DSP. I thought that VR couldn't be done without FFT.
I am still far away from having VR in my OS but your example gives "hope and strength" to continue (the attached image!).

DavidCooper · Post by **DavidCooper** » Sun Jan 25, 2015 3:04 pm

I'm confident that the brain doesn't use FFT either. The ear has a liquid-filled tube in which tiny hairs are pushed back and forth by that liquid as sound waves are sent through it, while different hairs are designed to resonate at different frequencies. I decided to try to copy that approach in software. Any noise (false results) generated by that approach must also be generated in the ear, though the brain may put a lot of processing into eliminating false resonances. It may be very costly to do the same in a computer processor where the brain will be using parallel processing, but I'll keep working on this whenever I have the time as there are still lots of possible ways left to speed things up further.

bigbob · Post by **bigbob** » Mon Feb 02, 2015 7:41 am

DavidCooper wrote:I'm confident that the brain doesn't use FFT either. ...

I can't comment on that, David

I realized that the power-states (page 151 of the Intel-specs) need to be set to D0 for the AFG-node and all of its nodes that has the PowerCtrl-bit set in WCaps.
I also clear TCSEL (PCI), as KolibriOS does.
The order of setting the regs and widgets are a little bit different from that of KolibriOS, I unmute and set the input-connections after the parse.
Unfortunately the DMA-engines are still not running

I am thinking about setting up all the DACs, not only the ones in two the paths (out and headph).

This is what parse finds (from PinOut to DAC):
Out-path: 0B 04
HeadPh-path: 0A 02

I parse two DWORDS of ConnListEntry (i.e. max 8 entries) of a given node.
This is the complete result of the parsing, if the found path is ignored (+ found, * notfnd):
parsing(LineOut): 0E *
parsing(speaker): 0B 04 + *
parsing(speaker): 0C 03 + *
parsing(speaker): 0F 05 + *
parsing(hpone): 0A 02 + *
parsing(first): 0A 02 + *
parsing(first): 0B 04 + *
parsing(first): 0C 03 + *
parsing(first): 0D 02 + *
parsing(first): 0E *
parsing(first): 0F 05 + *
parsing(first): 10 08 * 17 12 0E * 15 * 0F 05 + * 0B 04 + * 0C 03 + * 0D 02 + * 0A 02 **** 19 **

For example, 0B 04 is found (+), but is ignored (*) in order the parse to continue.
Another example (last line):
10 08 not found
10 17 12 0E not found
10 17 12 15 not found
10 17 12 0F 05 found
. . .

I know that it's highly unlikely that anybody has an idea why the DMA-engines still don't work (I read back from the DACs the stream, channel and format, and they were the ones I set), but at least the parse-part of HDAudio+Virtualbox is ready.

DavidCooper · Post by **DavidCooper** » Mon Feb 02, 2015 11:21 am

I can't run my OS and Windows at the same time due to failed batteries and a single functioning power lead, so I'll have to photograph numbers off screens to make comparisons. One thing I've noticed though is that when you do the following...

1. clear RUN-bit and interrupts in SD0CTL
2. set stream as output and streamId to 1 in SD0CTL
3. set stream format in SD0FMT to 0x4310 (I have a 11.025KHz, bits16, channelsNum=1; wav(PCM))
4. set LVI to 1
5. set BDL to address BDL_BUFF(0x170000) and set the two entries (LVI is 1):
entry1:
[BDL_BUFF] <-- 0x8F5000 (address of wav(PCM)-data)
[BDL_BUFF+4] <-- 0
[BDL_BUFF+8] <-- 88889 (length of PCM-data)
[BDL_BUFF+12] <-- 0 (no IOC)
entry2:
[BDL_BUFF+16] <-- 0x8F5000 (address of wav(PCM)-data)
[BDL_BUFF+16+4] <-- 0
[BDL_BUFF+16+8] <-- 88889 (length of PCM-data)
[BDL_BUFF+16+12] <-- 0 (no IOC)
6. set DPLBASE to 0x160000, and set bit0 to 1, to have the ctrller to write DMApositions
7. start stream: clear interrupts in SD0CTL and set bit1 to 1.

...I don't see you setting CBL:-

3.3.38 Offset 88: {IOB}SDnCBL – Input/Output/Bidirectional Stream Descriptor n Cyclic Buffer Length ... CBL must represent an integer number of samples.

It looks as if it's just left set to zero, so the DMA engine is stuck in one place, unable to move without being reset to where it already is:-

Registers:
GCAP:4401 VMIN:00 VMAJ:01 OUTPAY:003C INPAY:001D GCTL:00000001 WAKEEN:0000 STATESTS:0001 GSTS:0000 OUTSTRMPAY:00FF INSTRMPAY:00FF INTCTL:00000000
INTSTS:C0000000 WALCLK:0126C13D SSYNC:000000FF CORBLBASE:00140000 CORBUBASE:00000000 CORBWP:0000CORBRP:0000 CORBCTL:02 CORBSTS:00 CORBSIZE:42
RIRBLBASE:00150000 RIRBUBASE:00000000 RIRBWP:0000 RINTCNT:0000 RIRBCTL:02 RIRBSTS:00 RIRBSIZE:42 ICOI: 00000000 ICII:0000000 ICIS:0000
DPIBLBASE:00160001 DPIBUBASE:00000000 SD0CTL:00140002 SD0STS:00 SD0LPIB:00000000 SD0CBL:00000000 SD0LVI:0001 SD0FIFOD:0077 SD0FMT:4310
SD0BDPL:00170000 SD0BDPU:00000000

Starting up more DACs/ADCs isn't going to make any difference. You just want to have one active DAC set up to match the expectations of the DMA engine so that it can deliver data to something that will be happy to take data from it (though I'm not sure that's vital for the DMA engine to run).

bigbob · Post by **bigbob** » Mon Feb 02, 2015 12:04 pm

DavidCooper wrote: ...I don't see you setting CBL:-

That was it! Now the first DMA-position is 0x00015B39.
I still have no sound, but I consider this a big step ahead.
Thanks David!
I will check my whole code again tomorrow.
Who knows what else I forgot to set (or set incorrectly)

OSDev.org

HD Audio + Virtualbox

HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox

Re: HD Audio + Virtualbox