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

[vidrep]

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.

[diver]

Please attach the syslog as well.

[vidrep]

Attached are the syslogs from a fresh install of hrev49615.

[diver]

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

[miqlas]

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

[vidrep]

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

[vidrep]

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

[pulkomandy]

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

[modeenf]

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?

[ttcoder]

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.

[modeenf]

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?

[ttcoder]

@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 : ​https://git.haiku-os.org/haiku/tree/src/tests/add-ons/kernel/drivers/audio

[modeenf]

@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?

[modeenf]

I have a multi_audio_test. How do I use it?

this don't work.. multi_audio_test hda

[ttcoder]

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:

./multi_audio_test

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

[modeenf]

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)).

[ttcoder]

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*)

[mmlr]

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.

[vidrep]

Re-tested with update to hrev54465 x86_gcc2h - no change

[ttcoder]

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 :-).

[modeenf]

As a reference we have ​https://cgit.freebsd.org/src/tree/sys/dev/sound/pci/hda

Bu I also found out that HelenOS has it's own implementation, A smaller one and newer implementation. ​https://github.com/HelenOS/helenos/tree/master/uspace/drv/audio/hdaudio

Looking att some othe codec.h file I notised that

​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/audio/hda/hda_codec_defs.h, line 126 #define VID_SET_STRIPE_CONTROL 0x72000 Chould be #define VID_SET_STRIPE_CONTROL 0x72400

This did nothing for my bug, thoug.

For me our HDA code are realy complicated to follow. HelenaOS was some what easier but then it waqs not that big.

[korli]

Please check with hrev55842 or newer.

[vidrep]

Great news! Audio is now working. You can close this ticket.

[pulkomandy]

Great, thanks for testing!

[korli]

Nice, do headphones work as expected? Widgets in the media preferences displayed as expected?

[vidrep]

No audio output from the headphone jack, only from the built in speakers.

[vidrep]

After updating today to hrev55848 the headphone jack is now working. I didn't see any changes in the code since the last test that would account for that.

[korli]

Indeed. Maybe they were muted in Media preferences?