Opened 5 years ago

Last modified 8 weeks ago

#12356 new bug

[hda] 5 Series/3400 Series Chipset detected but no audio

Reported by: vidrep Owned by: korli
Priority: normal Milestone: Unscheduled
Component: Drivers/Audio/HDA Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking:
Platform: All


Installed hrev49615 x86_gcc2 on my HP Mini 311 netbook. Wireless and audio is not functional. Wired ethernet working OK. Video is VESA only. Attached listdev.

Attachments (7)

listdev (2.5 KB ) - added by vidrep 5 years ago.
previous_syslog (131.8 KB ) - added by vidrep 5 years ago.
syslog (429.1 KB ) - added by vidrep 5 years ago.
syslog_22_02_2016_Lenvo_x201.txt (71.9 KB ) - added by miqlas 5 years ago.
dmidecode.txt (9.1 KB ) - added by vidrep 3 years ago.
syslog.2 (143.5 KB ) - added by vidrep 3 years ago.
listdev.txt (2.5 KB ) - added by vidrep 3 years ago.

Download all attachments as: .zip

Change History (28)

by vidrep, 5 years ago

Attachment: listdev added

comment:1 by diver, 5 years ago

Please attach the syslog as well.

comment:2 by vidrep, 5 years ago

Attached are the syslogs from a fresh install of hrev49615.

by vidrep, 5 years ago

Attachment: previous_syslog added

by vidrep, 5 years ago

Attachment: syslog added

comment:3 by diver, 5 years ago

Component: - GeneralDrivers/Audio/HDA
Owner: changed from nobody to korli
Summary: HP Mini 311 No audio or wireless[hda] 5 Series/3400 Series Chipset detected but no audio

Graphics driver issues are tracked in #5543. Wireless driver issue is here #6474. Does blacklisting hda driver and installing opensound make audio work?

comment:4 by miqlas, 5 years ago

Here is my syslog: Lenovo X201, also with Intel 5 Series/3400. Tested with gcc2h hrev50095, with vanilla hda and with oss. Not working.

by miqlas, 5 years ago

comment:5 by vidrep, 4 years ago

Updated to hrev50475 x86_gcc2 and installed OSS and blacklisted hda driver. Still no audio.

comment:6 by vidrep, 3 years ago

Still a problem on hrev51775 x86_gcc2h. Attached listdev.txt, dmidecode.txt, and syslog.txt

by vidrep, 3 years ago

Attachment: dmidecode.txt added

by vidrep, 3 years ago

Attachment: syslog.2 added

by vidrep, 3 years ago

Attachment: listdev.txt added

comment:7 by pulkomandy, 2 years ago

Milestone: UnscheduledR1/beta2

comment:8 by pulkomandy, 10 months ago

Milestone: R1/beta2Unscheduled

Removing HDA audio tickets from Beta2 milestone, no one has worked on it and opensound is available at least as a stopgap.

comment:9 by modeenf, 8 months ago

I have the same problem..

Don't know if it's some relation to #14581 or #14242.

If I look at my logs I have "KERN: hda: DMA snooping: no" sounded bad if you read comments at #14581

My id is 3b56, vendor 8086. and both exists in, hda_controller.cpp.. and the dev/ path exist to the driver :). What else can one test?

comment:10 by ttcoder, 8 months ago

Yeah waddlesplash mentionned in #14581 that it makes no sense to have two different behaviors for DMA on my T410 depending on the phase of the moon, yet this is what I get :-).. On R1/b1 it goes "yes", whereas right now I'm booted in old 50465 and it goes...

KERN: hda: enabling PCI interrupts
KERN: hda: DMA snooping: no

And in both case ("yes" and "no") I can listen to music without much trouble (apart from the need to restart media after boot up as media_addon_server crashes, and/or wait a few minutes after boot) with the following hardware:

device Multimedia controller (Audio device) [4|3|0]
  vendor 8086: Intel Corporation
  device 3b56: 5 Series/3400 Series Chipset High Definition Audio

(the vendor+device ID is not enough to identify precisely an HDA device BTW, I think one needs to dig in the syslog for sub-IDs)

To further complicate matters, sometimes the HDA driver works great, yet media_server fails to send buffers to it, for 30 minutes or more after boot up (that's what I get with R1/b1, but never in the old hrev). So if you feel courageous, you could try to quit/disable media services and test with a bare-bones sine-wave generator that talks directly to the HDA driver, to make sure you lack of audio is not caused by the server, but is indeed caused by the HDA driver itself. I'm not sure where it is, it's been years.. It might be this one here.

EDIT: yeah that seems to be the one, it calls B_MULTI_BUFFER_EXCHANGE directly, and fills buffers with sin()

EDIT: I'll go to my grave believing the lack of a media-bypassing sine wave "test" is one of the great mistakes Haiku made by the way.. So much time wasted, when a simple "test audio" button somewhere could have helped in many situations.

EDIT: got word from A.D. that including multi-audio-test in the nightly images is a definite "nein". So to people who want to test with that, either you compile it yourself or... YOYO. SNAFU.

EDIT: Anyhow, see ticket:14581#comment:19 for a "work-around" to initialization problems in the HDA driver itself.

Last edited 8 months ago by ttcoder (previous) (diff)

comment:11 by modeenf, 6 months ago

Nice will try to test the bypassing the media_server if I can make it build :)

I have

KERN: hda: DMA snooping: yes

I have no

KERN: hda: enabling PCI interrupts

Can I test something else?

comment:12 by ttcoder, 6 months ago

@modeenf please try this:

  • Try the recommendation in ticket:14581#comment:19 (first boot to linux or BSD, then warm-reboot to haiku and test audio)

If that is not successful, I'd recommend compiling Haiku from source, including this bit, and use it to diagnose the problem :

comment:13 by ttcoder, 6 months ago

Cc: ttcoder added

comment:14 by modeenf, 6 months ago

@ttcoder.. don't have other system installed :).

I can test that anyway.

One thing I notice on another laptop that do work (aspire one d255). First I thought that it was broken there as well. When I investigate the problem I found that it was muted.. and I hade like 5-6 outputs so I had to scroll to get to the one that was muted.

I don't know anything about hardware driver. But what if by default the sound was muted and as we don't have a working media addon to unmute, the sound will stay mute?

comment:15 by modeenf, 6 months ago

I have a multi_audio_test. How do I use it?

this don't work.. multi_audio_test hda

comment:16 by ttcoder, 6 months ago

Glad you could setup and build it! It should work something like this:

  • open a Terminal precisely in the directory where "multi_audio_test" was built.

Check that it runs invoking it with dot-slash:


If your terminal is cd'ed in the right directory, it will find the executable, which will guide you about a missing argument:

Usage: multi_audio_test <device>

So invoke it with the correct argument, typically :

./multi_audio_test /dev/audio/hmulti/hda/0

Then in the resulting prompt you can type "help" to list the available prompt commands. The interesting one here is likely "play" : if that commands is silent, it will confirm that the HDA driver is the culprit. Otherwise it's media_server.


By the way, you will probably need to shut down the media_server first before doing any of the above, or the above command will not be able to open the device:

launch_roster stop x-vnd.haiku-media_server
kill media_server
kill media_addon_server

comment:17 by modeenf, 6 months ago

thanks, I was missing the 0 in "./multi_audio_test /dev/audio/hmulti/hda/0" and the kill command was a big help :)

no tone. If it was the media_server problem then mute/unmute could be the problem? So this is not a mute problem..

this was my out put

> play
format 32bit (0x1000)
sample rate 48000 (0x100)
playback: buffer count 2, channels 2, buffer size 2048
  Channel 0
    [0] buffer 0x826e7000, stride 8
    [1] buffer 0x826eb000, stride 8
  Channel 1
    [0] buffer 0x826e7004, stride 8
    [1] buffer 0x826eb004, stride 8
record: buffer count 2, channels 2, buffer size 2048
24 buffers exchanged while playing (49152 frames played (49129)).

comment:18 by ttcoder, 6 months ago

Well then you seem to be (logically) in the same situation as me, or presumably vidrep, or others with a "5 Series/3400 Series Chipset" : the chipset requires initialization from another OS'es driver. If that's any consolation to you, I'm allergic to using anything else than Haiku too, and despite that I made this laptop my primary laptop, for the following reasons:

  • I do *not* have to use the "boot secondary OS" trick more than *once per week*. Not sure what kind of magic that is, or if it's reproducible on other laptops of the same type, but for me the initialization is remembered for about 24 hours after I shutdown (switch off) the laptop. I only have to use the trick after a 2 days week-end, so that's not painful.
  • The "alternate" OS I use does not waste my time or disk space : it's just a 2GB USB stick with Genode (SculptOS) that boots up in 6-7 seconds (take that Haiku :-), the install image is quick to download even with my lame internet access, and it installs with dd in a dozen seconds.

Or alternatively, you can wait for the Haiku driver to be fixed.....

(at any rate we probably should take discussions about booting to other OS'es to the haiku forums to not annoy the many recipients of emails for this ticket *g*)

comment:19 by mmlr, 2 months ago

I have not investigated whether or not the multi_audio_test would be affected by the same drift calculation problem fixed in hrev54464, but it is possible. So please retest with a nightly including that fix.

There have been other recent fixes to HDA relating to the interrupt setup changing on reopen as well as physical memory corruption on stream reconfiguration. Depending on how the multi_audio_test works the latter may be relevant. The former, i.e. changing interrupt method after reopen, would definitely come into play when switching from media_server to another application, thereby reopening the driver.

comment:20 by vidrep, 8 weeks ago

Re-tested with update to hrev54465 x86_gcc2h - no change

comment:21 by ttcoder, 8 weeks ago

So unfortunately, it sounds like this would indeed locate this ticket in the "reboot to other OS to enable HDA" category, unlike some other tickets that were in the "driver works, just needs to wait a few minutes after boot" category, which was addressed by a recent commit.

(ps. the test/addons/audio/... test talks to the hda driver directly, with an incredibly small codebase of a few dozen lines of code that basically just call B_MULTI_BUFFER_EXCHANGE to feed a sine wave to the driver ; by contrast, the code in BMediaFile/BSoundPlayer and the ffmpeg/libav code that it relies on, and the media_server and BTimeSource that it relies on, and the media_addon_server and its audio-mixer add-on, are several dozen thousand lines of code.. So the interest for the latter in trouble-shooting audio problems is obvious :-).

(edit: maybe I should rephrase as "the interest in the test binary was obvious", past tense ; if the media server audio chain has no more heisenbugs now, it might be reasonable to assume from now on that HDA output problems are indeed in the HDA driver)

Last edited 8 weeks ago by ttcoder (previous) (diff)
Note: See TracTickets for help on using tickets.