Intel High Definition Audio problem. [SOLVED]

[DavidCooper]

I've spent a bit of time over the last few weeks adding audio capability to my OS with the aim of giving it very basic speech recognition capability (with the initial plan being to get it to recognise the names of keys so that I don't have to type them any more - this will cut down on RSI problems and enable USB controller exploration without worrying about losing all means of input along the way). I'm planning to write a device driver for Intel High Definition Audio sound cards (and will continue to develop the wiki entry as I do so: http://wiki.osdev.org/Intel_High_Definition_Audio), but so far I've only written experimental code which is specific to the particular Realtek 662 codec in my machine (while working directly from the codec's datasheet and its map of widgets).

The problem:-

I've actually got enough working to do what I need, but the built-in speakers refuse to respond and it would obviously be a lot better if I could get them working too. I can get stereo sound out through the headphone socket, and I can also get sound in through both the mic. socket (in stereo) and from the built-in microphone (in mono), but the speakers only give me a click on reset at best. I'm now wondering if there's something blocking access to the speakers, such as the way the BIOS has set up the machine. Experimentation shows that the BIOS beep stops working as soon as I do a reset in the sound card's Global Control Register, so that's the prime focus of my suspicions at the moment. If this is a common problem and not just a mistake I'm making somewhere such as a hidden mute in a widget (I've checked very carefully and I'm sure I've found them all) it'll be difficult to complete the wiki entry in a satisfactory way until this issue is resolved.

A lesser issue is that the volume keys and mute key (which on my machine need the Fn key to be held down too) do absolutely nothing to the volume level at all and they don't show up as keypresses either. I'm not too bothered about that as I can just use the Ctrl key with same keys instead and then adjust the volume at the amplifiers, but if there is a direct fix for this it would be good to know what it is so that it can be added it to the wiki too.

[Owen]

For volume/etc keys there are two possibilities:

• If this is a laptop, they may be ACPI buttons (and therefore will require ACPI support_
• If this is an external USB keyboard, they will be coming through as USB key IDs, which the BIOS is presumably translating into legacy scancodes for you. Because legacy keyboards never had these keys, the BIOS is probably dropping them

[Asper]

The problem is probably in a wrong widgets configuration or settings for the stream.
I have written HD audio driver for KolibriOS. You can try to test it on your hardware and if it works for it, we can get full driver/codec conversation log for your hardware for the proper configuration.

Latest KolibriOS builds
http://builds.kolibrios.org/eng/latest-img.7z
http://builds.kolibrios.org/eng/latest-iso.7z

[rdos]

I had a lot of trouble with speakers in lap tops as well. A major issue (apart from parsing the connection tree) is to know which widget actually is the internal speaker. In my code, I look for a pin-complex with the "fixed" connectivity property, and assume this is the internal speaker, and this works on at least 2 different laptops.

Besides, you really should parse the connection-tree and not use your knowledge about a specific codec. It's a lot of work, but if you do it, you will support almost all modern computers.

[Asper]

In my code, I look for a pin-complex with the "fixed" connectivity property, and assume this is the internal speaker, and this works on at least 2 different laptops.

What do you mean by "fixed" connectivity propety?

Code: Select all

AC_JACK_LINE_OUT             equ 0x0
AC_JACK_SPEAKER              equ 0x1
AC_JACK_HP_OUT               equ 0x2

Code: Select all

proc parse_output
        push    edx
        ; Look for the output PIN widget
        ;
        ; first, look for the line-out pin
        stdcall parse_output_jack, AC_JACK_LINE_OUT
        test    eax, eax
        jz      @f
        mov     [spec.out_pin_node], eax   ; found, remember the PIN node
        jmp     .l1
  @@:
        ; if no line-out is found, try speaker out
        stdcall parse_output_jack, AC_JACK_SPEAKER
        test    eax, eax
        jz      .l1
        mov     [spec.out_pin_node], eax   ; found, remember the PIN node
  .l1:
        ; look for the HP-out pin
        stdcall parse_output_jack, AC_JACK_HP_OUT
        test    eax, eax
        jz      .l2

        mov     edx, [spec.out_pin_node]
        test    edx, edx
        jnz     @f
        mov     [spec.out_pin_node], eax
        jmp     .l2
  @@:
        mov     [spec.out_pin_node+4], eax
  .l2:
        mov     edx, [spec.out_pin_node]
        test    edx, edx
        jnz     @f
        ; no line-out or HP pins found,
        ; then choose for the first output pin
        stdcall parse_output_jack, -1

        mov     [spec.out_pin_node], eax
        test    eax, eax
        jnz     @f
     if DEBUG
        push    esi
        mov     esi, emsgNoProperOutputPathFound
        call    SysMsgBoardStr
        pop     esi
     end if
  @@:
        pop     edx
        xor     eax, eax
        ret
endp

Besides, you really should parse the connection-tree and not use your knowledge about a specific codec. It's a lot of work, but if you do it, you will support almost all modern computers.

Yes, the driver for KolibriOS should support almost all HDA hardware, because it has generic parser for the codecs widgets.

[rdos]

In my code, I look for a pin-complex with the "fixed" connectivity property, and assume this is the internal speaker, and this works on at least 2 different laptops.

What do you mean by "fixed" connectivity propety?

Code: Select all

AC_JACK_LINE_OUT             equ 0x0
AC_JACK_SPEAKER              equ 0x1
AC_JACK_HP_OUT               equ 0x2

We use different ways to detect. What you refer to above is the device-type. I use the connectivity parameter. I'm not sure if these methods differ or not, but using the device-type would also work on one of my lap-tops, as the only output that is fixed also has AC_JACK_SPEAKER. It is unfortunate that the specification doesn't deal with this.

[Asper]

You probably speak about Port Connectivity bits in the Configuration Default register.
I would not rely on this option, because it do not work in most cases.

[rdos]

You probably speak about Port Connectivity bits in the Configuration Default register.
I would not rely on this option, because it do not work in most cases.

Can you give some examples of it not working? It works on the laptops I've tested on.

Besides, it seems like you rely on the Default Device in the Configuration Default register, and you should realize that there are a lot more than 3 different types. The specification I have has 14 defined types, and an additional (vendor specific, probably) of them says "other". The Port connectivity only defines 4 types, and type 2 (fixed) should be used by all implementations of internal speakers. However, as usual, the truth might not be what is most logical, as the issue here is how people interpret the specifications.

In addition to that, there is a dynamic aspect of jacks (Port Connectivty type 0). If the laptop has an internal speaker, and the user connects an external speaker to a jack, the OS should use the jack rather than the internal speaker.

Link to HD codec interface code for RDOS: http://rdos.net/vc/viewvc.cgi/trunk/ker ... iew=markup

Edit: On further inspection of the code, it turns out that I require both Port Connectivity to be 2 and Default Device to be 1.

[Combuster]

In addition to that, there is a dynamic aspect of jacks (Port Connectivty type 0). If the laptop has an internal speaker, and the user connects an external speaker to a jack, the OS should use the jack rather than the internal speaker.

And the sensor is the first thing that breaks on a laptop - three different brands tested. Making that quite a particular misfeature.

[Asper]

Asper wrote:
You probably speak about Port Connectivity bits in the Configuration Default register.
I would not rely on this option, because it do not work in most cases.


Can you give some examples of it not working? It works on the laptops I've tested on.

Edit: On further inspection of the code, it turns out that I require both Port Connectivity to be 2 and Default Device to be 1.

Several examples:

HP EliteBook 8730w

Pin configurations:
Q: 011F1C00
A: 02212040
Q: 012F1C00
A: 01014010
Q: 013F1C00
A: 413711F0
Q: 014F1C00
A: 02A12060
Q: 015F1C00
A: 91A7112E
Q: 016F1C00
A: 9217411F
Q: 017F1C00
A: 41A6E130
Q: 01AF1C00
A: 90F711F0
Q: 01BF1C00
A: 98561150
Q: 01CF1C00
A: 01813021
Q: 001F2000
A: 103C30EC
Analog Devices unknown codec id 0000194A

eBox 3300MX

Pin configurations:
Q: 111F1C00
A: 411111F0
Q: 112F1C00
A: 411111F0
Q: 114F1C00
A: 01014110
Q: 115F1C00
A: 411111F0
Q: 116F1C00
A: 411111F0
Q: 118F1C00
A: 411111F0
Q: 119F1C00
A: 01A19920
Q: 11AF1C00
A: 411111F0
Q: 11BF1C00
A: 411111F0
Q: 11CF1C00
A: 411111F0
Q: 11DF1C00
A: 598301F0
Q: 11EF1C00
A: 411111F0
Q: 11FF1C00
A: 411111F0
Q: 10BF2000
Realtek ALC262

Zotac NM 10-ITX

Pin configurations:
Q: 214F1C00
A: 01014010
Q: 215F1C00
A: 411111F0
Q: 216F1C00
A: 411111F0
Q: 218F1C00
A: 01A19830
Q: 219F1C00
A: 02A19831
Q: 21AF1C00
A: 0181303F
Q: 21BF1C00
A: 0221401F
Q: 21CF1C00
A: 411111F0
Q: 21DF1C00
A: 4004C601
Q: 21EF1C00
A: 01446120
Q: 20AF2000
Realtek ALC662

But you are right on many codecs (i.e. from Realtek) it works. It work on EeePC for example.

Besides, it seems like you rely on the Default Device in the Configuration Default register, and you should realize that there are a lot more than 3 different types. The specification I have has 14 defined types, and an additional (vendor specific, probably) of them says "other".

Mine too. I use "Intel® I/O Controller Hub 6 (ICH6) High Definition Audio / AC ’97 Programmer’s Reference Manual (PRM) May 2005" and a newer version of it "High Definition Audio Specification, Revision 1.0a, June 17, 2010".

full version of that piece of code looks like this

Code: Select all

; device types (0x0-0xf)
AC_JACK_LINE_OUT             equ 0x0
AC_JACK_SPEAKER              equ 0x1
AC_JACK_HP_OUT               equ 0x2
AC_JACK_CD                   equ 0x3
AC_JACK_SPDIF_OUT            equ 0x4
AC_JACK_DIG_OTHER_OUT        equ 0x5
AC_JACK_MODEM_LINE_SIDE      equ 0x6
AC_JACK_MODEM_HAND_SIDE      equ 0x7
AC_JACK_LINE_IN              equ 0x8
AC_JACK_AUX                  equ 0x9
AC_JACK_MIC_IN               equ 0xA
AC_JACK_TELEPHONY            equ 0xB
AC_JACK_SPDIF_IN             equ 0xC
AC_JACK_DIG_OTHER_IN         equ 0xD
AC_JACK_OTHER                equ 0xF

I do not support other types of sound output yet, not SPDIF nor HDMI.

In addition to that, there is a dynamic aspect of jacks (Port Connectivty type 0). If the laptop has an internal speaker, and the user connects an external speaker to a jack, the OS should use the jack rather than the internal speaker.

This requires support for Unsolicited Response, it is on my TODO list.

Link to HD codec interface code for RDOS: http://rdos.net/vc/viewvc.cgi/trunk/ker ... iew=markup

Here is link to the driver for KolibriOS: http://websvn.kolibrios.org/listing.php ... ff29e5347a

[rdos]

In addition to that, there is a dynamic aspect of jacks (Port Connectivty type 0). If the laptop has an internal speaker, and the user connects an external speaker to a jack, the OS should use the jack rather than the internal speaker.

And the sensor is the first thing that breaks on a laptop - three different brands tested. Making that quite a particular misfeature.

At least it is the best alternative that doesn't require any type of configuration or user interaction. Which is one of the primary design goals in RDOS. If you prefer a few thousand lines of audio configuration that the user either doesn't know exist at all, or find impossible to figure out, that's fine.

[rdos]

It actually should be the HP EliteBook that should work, and not the RTL-versions.

HP EliteBook 8730w

Pin configurations:
Q: 015F1C00
A: 91A7112E

Port Conn = 2
Location = 11
Device = A

Q: 016F1C00
A: 9217411F

Port Conn = 2
Location = 12
Device = 1

Q: 01AF1C00
A: 90F711F0

Port Conn = 2
Location = 10
Device = F

Q: 01BF1C00
A: 98561150

Port Conn = 2
Location = 8
Device = 5

This means it is device 16h that has both Port Conn = 2 and Device = 1. That computer should work with my algorithm.

BTW, my Compaq Presario CQ57 portable has an Realtek ALC270, and it works.

[Asper]

Not sure how to interpret these logs

Q - is the driver query to the codec
A - is the codec's answer
i.e.
Q: 011F1C00
means: [Codec Address = 0][Node ID = 0x11][Command = AC_VERB_GET_CONFIG_DEFAULT = 0xF1C][Parameter = 0]
A: 02212040
means: [Port Connectivity = AC_JACK_PORT_COMPLEX = 0][Location = AC_JACK_LOC_EXTERNAL:AC_JACK_LOC_FRONT = 0:2][Default Device = AC_JACK_HP_OUT = 2][Connection Type = AC_JACK_CONN_1_8 = 1][Color = AC_JACK_COLOR_GREY = 2][Misc = 0][Default Association = 4][Sequence = 0]

Q: 012F1C00
means: [Codec Address = 0][Node ID = 0x12][Command = AC_VERB_GET_CONFIG_DEFAULT = 0xF1C][Parameter = 0]
A: 01014010
means: [Port Connectivity = AC_JACK_PORT_COMPLEX = 0][Location = AC_JACK_LOC_EXTERNAL:AC_JACK_LOC_REAR = 0:1][Default Device = AC_JACK_LINE_OUT = 0][Connection Type = AC_JACK_CONN_1_8 = 1][Color = AC_JACK_COLOR_GREEN = 4][Misc = 0][Default Association = 1][Sequence = 0]

but are you saying that it would be enough to look at the Default Device type, and that looking at the Port Connectivity option is not necessary?

You can use Port Connectivity as a supplementary option to configure the codec to output sound, but not the main one.
You have to:

• 1. Get all Pin widgets Default Configurations Widget Capabilities and Audio Widget Capabilities,
  2. Sort Pin widgets by Default Association:Sequence
  3. Starting from the least (by DA:Sequence) Pin widget
  • a. check if the Pin widget output capable in the Pin capabilities, if not skip it and try the next Pin widget
    b. check if Port Connectivity = AC_JACK_PORT_NONE = 1, if yes skip it and try the next Pin widget
    c. check if the Pin widget is not a digital one (to skip SPDIF nodes, if you don't support it yet) in the Audio Widget Capabilities, if not skip it and try the next Pin widget

After that output should go to the right Pin widget.

[rdos]

The computers you have listed that doesn't support my algorithm both has non-zero codec addresses. Are you really sure that this is correct? I have one computer which has two codecs, one of which is non-functional (built-into the chipset), and it required a little pecularities to detect that it was not functional, despite reporting codec configurations.

Edit: In fact, none of the one's with non-zero codec address has a valid pin-widget with a device type = 1!

[DavidCooper]

For volume/etc keys there are two possibilities:

• If this is a laptop, they may be ACPI buttons (and therefore will require ACPI support_
• If this is an external USB keyboard, they will be coming through as USB key IDs, which the BIOS is presumably translating into legacy scancodes for you. Because legacy keyboards never had these keys, the BIOS is probably dropping them

Thanks - it's the first of those, so it's something that will only get its fix well down the to-do list, and that means a temporary fix needs to be used in the mean time. I realise now that the ctrl keys would be a useless alternative to the Fn key as the function keys used for volume vary wildly between different machines, while others can have proper dedicated buttons instead, so I'm now thinking of using something absolutely constant like the Alt Gr key with up/down cursor keys (and left/right for microphone volume).