Re: Problems with hdaudio(4) on Dell Optiplex-5050

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Investigating this further reveals the following additional
information and yields more specific questions which I hope someone can help
me with.

	The freeBSD-12 driver for this audio chip only knows how to drive the
line out jack on the back of the machine.  If I modify hdafg.c to remove
the fix posted to Rev1.16 of hdafg.c, the NetBSD driver behaves the same
way.  That is, only the line out jack is active.  However, in both FreeBSD
and netBSD cases, the line out provides good stereo output.

	When I plug in a headphone set when audio is playing through the
internal speaker, using the headphone jack on the front of the machine, I
get a momentary blip where the sound is correct through the headphones
before the cross channel cancelation takes effect.  
Others have described the same problem on Dell equipment, so I don't think
this is a hardware problem, though folks on the thread referenced below
also thought it might be a hardware problem.

	I've downloaded and tried to wade through the HD Audio specification
from Intel, and it definitely helps my understanding of how the driver
works, but I still don't quite understand how codec streams get connected
to output pins and where the associations between related pins happens.  I
think the problem is that when the presence detect happens on the headphone
jack and the presence handler is called in hdafg.c, the only thing that
routine does is enable output on the headphone jack, without making any
other changes to the stream.  What I think needs to happen, and this is
where my understanding begins to faulter, is that in addition to changing
the setting of the output device, the codec->output device association
needs to change to reflect the changed characteristics of the newly enabled
output device.  I have a similar audio chip on a Dell Windows 10 laptop and
I can tell by the way it behaves, that it definitely alters these
associations on the fly as one switches betweeninternal speakers and
headphones.  The windows driver  also asks me whether I've plugged in a
headphone or external speaker, or something else, so there's definitely
some kind of software control over the jack and what it's being used for.
It looks like our driver needs some work to increase the sophistication of
this process.  Right now, for example, there appears no way to attach a
microphone device.  
In fact, as I think about it, I wonder if that's part of the problem.  I
wonder if there's an additional contact in the jack that is to be used for
a microphone that's supposed to be disabled in software when a headphone or
speaker is attached?

	Any enlightenment anyone can shed on this work would be greatly
appreciated.

-thanks
-Brian


https://www.unitedbsd.com/d/286-bad-audio-on-netbsd