Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#16222 closed bug (fixed)

hda: silent for 4 minutes after boot

Reported by: miqlas Owned by: korli
Priority: normal Milestone: R1/beta3
Component: Add-Ons/Media/hmulti_audio Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking: #16325
Platform: All

Description

A regression in hrev54299 x86_64 Haiku, on a T440s laptop. So far audio worked flawelessly, but since some revisions hda is silent for around 4 minutes, then it magically starts to work.

Grepped syslog in the attachment. I don't know which version worked last time.

Attachments (1)

hda.log (51.8 KB ) - added by miqlas 4 years ago.
grepped syslog

Download all attachments as: .zip

Change History (19)

by miqlas, 4 years ago

Attachment: hda.log added

grepped syslog

comment:1 by ttcoder, 4 years ago

Cc: ttcoder added

As noted elsewhere, this already occured ten years ago in Haiku Alpha1, when people were using SB-Lives, or (in my case) Ensoniq-PCI, or AC97 and others. So the if the bug is in the HDA driver, that would mean the same bug is replicated in other drivers too. It seems more likely there is a timestamp problems in BBuffers or some such... Though HDA is not impossible I guess.

FWIW, in our stations we added a little script to delay media_server usage by 30 seconds after boot up, that seems to work-around the problem.

Last edited 4 years ago by ttcoder (previous) (diff)

comment:2 by Starcrasher, 4 years ago

Noticed it too. Last rev ok seems to be 54282 then there's a delay.

comment:3 by ttcoder, 4 years ago

Still there in beta2, FWIW

Related : #15742, maybe also #15720

Last edited 4 years ago by ttcoder (previous) (diff)

comment:4 by ttcoder, 4 years ago

Blocking: 16325 added

comment:5 by kim1963, 4 years ago

hrev54459 - The sound turned on spontaneously 23 minutes 30 seconds after the start of the operating system.

comment:6 by waddlesplash, 4 years ago

Should be fixed after hrev54464, please retest.

comment:7 by miqlas, 4 years ago

Will do, thank you!

comment:8 by ttcoder, 4 years ago

It might make sense to backport the fix to the beta2 branch, to lower the "barrier to entry" (although it's not all that high)

comment:9 by pulkomandy, 4 years ago

Maybe, but it would be nice if we get confirmation that the issue is actually fixed, first?

comment:10 by miqlas, 4 years ago

Works ok, sorry for the late feedback.

comment:11 by ttcoder, 4 years ago

Component: Drivers/Audio/HDAAdd-Ons/Media/hmulti_audio
Milestone: UnscheduledR1/beta3
Platform: x86-64All

Nice! Setting fields so that it's ready to close as "fixed in beta3", though I feel it's more up to a haiku dev to give the final go-ahead on closing this.

Last edited 4 years ago by ttcoder (previous) (diff)

comment:12 by waddlesplash, 4 years ago

Resolution: fixed
Status: newclosed

comment:13 by ttcoder, 4 years ago

Feel like adding the one-liner fix to the beta2 branch ?

comment:14 by waddlesplash, 4 years ago

There was a whole series of HDA and multi_audio fixes; I'm not sure it's definitively a "one line fix".

comment:15 by ttcoder, 4 years ago

I was referring to the below, but.... serves me well for asking, as usual, I guess :-)

Replying to waddlesplash:

Should be fixed after hrev54464, please retest.

comment:16 by waddlesplash, 4 years ago

Yeah, there were a lot of other HDA and multi_audio changes before that one which may also be related.

in reply to:  16 comment:17 by mmlr, 4 years ago

Replying to waddlesplash:

Yeah, there were a lot of other HDA and multi_audio changes before that one which may also be related.

They aren't. The fix is standalone and can safely be applied as is. It also can't cause regressions, so backporting this to the beta branch would indeed be nice (at least if it isn't much of an effort).

comment:18 by waddlesplash, 4 years ago

You can submit the relevant commits yourself by clicking Rebase in Gerrit and then submitting.

Note: See TracTickets for help on using tickets.