oui Listning to Spotify now after a reboot and no issues with the sound.

dmesg reports hdaudio0: autoconfiguration error: RIRB timeout >180 times but, eventually it connects

[     1.035793] hdaudio1 at pci0 dev 27 function 0: HD Audio Controller
[     1.035793] hdaudio1: interrupting at msi3 vec 0
[     1.035793] hdafg0 at hdaudio1: vendor 111d product 76e0
[     1.035793] audio0 at hdafg0: playback, capture, full duplex, independent
[     1.035793] audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
[     1.035793] audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
[     1.035793] spkr0 at audio0: PC Speaker (synthesized)

..and works perfectly.

  • oui replied to this.
  • oui likes this.

    pin Thanks for testing Pin! Then it seems my problem may lie somewhere else.

    • pin replied to this.

      oui Det var så lite så 😉
      I wish I could help...

      • oui likes this.

      oui Turns out I can get output from hdaudioctl - I had to specify -f /dev/hdaudio1

      I see. Maybe your HDMI/DP audio is /dev/hdaudio0 because I don't see it in the list output. And, the alsa-info.sh output also shows HDMI as the first audio device on Linux. (It's the second on mine and connected to hdaudio0 also, as you can see.)

      oui Also worth noting that 3/10 times during boot this message below gets printed out repeatedly covering the entire screen:

      If /dev/hdaudio0 is HDMI audio, then those messages might (or might not) go away once the DRMKMS driver takes over; or, some internal timeout expires; or, once a HDMI monitor is attached. Whatever (see how unambiguously positive I am in my answer? Not hand-wavey at all)...

      oui Unfortunately none of this fixes the audio artifacts I'm experiencing.

      Try these two things:

      1. Make a connection graph using hdaudioctl -f /dev/hdaudio1 graph codecid nid > /tmp/somefile.dot. Then convert the .dot file to a .png image using Graphviz Online. On the Linux side, follow instructions here: codecgraph
        We'll see if the NetBSD driver wires your audio subsystem up the same way as Linux does.

      2. As a quick test, can you edit your .plist file and change the speaker and HP (and possibly microphone?)dicts (nids 0x14 and 0x21, resp.) so that the config key values match the corresponding ones in mine? (change only config, leave nid alone.)

        13 days later

        rvp Thanks a ton rvp! I'm learning a lot here and I really appreciate your input.
        So the other day I finally got my hands on another exact same model (Dell Optiplex 3020M) and installed linux on it - tested to install NetBSD 9 and current prior to installing linux and the same sound artifacts still remained.

        Linux graph:

        NetBSD graph:

        rvp As a quick test, can you edit your .plist file and change the speaker and HP (and possibly microphone?)dicts (nids 0x14 and 0x21, resp.) so that the config key values match the corresponding ones in mine? (change only config, leave nid alone.)

        Changing my config key values to match yours did not unfortunately fix the problem but I got some interesting results - I now only have output from one DAC (DAC00) and only one master.outputs, sound from speakers get automatically muted when headphones are plugged in but similar sound artifacts with each audio channel outputting sound to both left and right speaker at the same time still remains.

        • rvp replied to this.

          oui but I got some interesting results - I now only have output from one DAC (DAC00) and only one master.outputs, sound from speakers get automatically muted when headphones are plugged

          Yes, and when I changed my config keys to match yours a few weeks ago, I managed to duplicate your sound setup😁: 2 DACs; independent speaker and HP; and the inability to shift balance using audioctl--but no sound-bleeding artifacts.

          Thanks for the diagrams, I'll look 'em over in detail during the weekend, but, it looks like you will need kernel fixups. Linux has these "fixups" for the widgets in case the BIOS mis-configures things; NetBSD simply uses what the BIOS set-up.

          I'll send you a test patch on the weekend. In the meantime, try updating to the latest BIOS.

            rvp I'll send you a test patch on the weekend.

            Please don't feel obligated to and by all means take as much time as you need, cheers! 😄

              rvp In the meantime, try updating to the latest BIOS.

              Also try fiddling with sound settings in BIOS (if any).

              • oui likes this.
              a month later

              oui Can you compile a GENERIC kernel with this option uncommented:

              options        HDAUDIOVERBOSE  # verbose HDAUDIO driver messages

              and these options added:

              options        HDAUDIO_DEBUG
              options        HDAFG_DEBUG=2
              options        HDAFG_HDMI_DEBUG

              and post the dmesg output?

              • oui likes this.

              rvp dmesg output of compiled kernel with verbose HDAUDIO / HDAFG debug options: https://pastebin.pl/view/f8b881ff

              rvp On the mailing-list: another Dell Optiplex model with the same issue.

              Interesting, so it seems the bug isn't exclusive to the Dell Optiplex model I have.

              • rvp replied to this.
              • rvp likes this.

                Make another one like this:

                1. play audio on speaker for 15 secs.
                2. plug-in HP
                3. Wait 15 secs. unplug HP.
                4. Save dmesg

                oui Interesting, so it seems the bug isn't exclusive to the Dell Optiplex model I have.

                He will need patches too...

                  oui There you go

                  It doesn't have what I want (as I suspected). Let's see how Linux changes the vendor widgets instead: Can you use the latest alsa-info.sh (see post #10) and upload 2 outputs the same way? Once before the HP is plugged in and once after?

                  • oui likes this.

                  More from the mailing-list. I had come to the same conclusion myself.
                  This means that, until the code is ready, you can apply a hardware "fix" to this software problem: try connecting a HP with mic.

                  3 months later