On Thu, 14 Nov 2024 01:04:22 +0100,
Jarosław Janik wrote:
>
> On 8.11.2024 15:17, Takashi Iwai wrote:
> > OTOH, a question is rather the other route -- the beep via pcspkr
> > driver -- if this beep still works while the HD-audio is runtime
> > suspended: that's the interesting point. Could you check that?
> > You can figure out which input device corresponds what, and try to
> > trigger directly there.
>
> Beep via pcspkr module works fine without your patch - regardless of
> current PM state of HDA device; with your patch applied - the beep is
> very quiet if HDA is suspended (same as with firmware generated beeps).
>
> > Also, one more question is whether the beep tone persists if you mute
> > the volume on the HD-audio (e.g. set "Speaker Playback Switch" to
> > off). The beep tone at shutdown should be gone in this state, too.
>
> pcspkr generated beeps are immune to every mixer/switch setting except
> for "Master Mute Switch", which mutes them completely (i.e. they are not
> very quiet, they are gone). And again - this is the very same as with
> firmware beeps; that would mean that both (firmware's and pcspkr's) are
> using PIT to drive "PC Speaker".
So, if the HD-audio Master volume influence on the beep output of
pcspkr, it means that it's flowing over HD-audio, likely there is some
analog-input loopback.
Could you give alsa-info.sh output? (Run with --no-upload option and
attach the output).
If there is a mixer widget there, one of input pins might correspond
to the analog beep input -- even if the pin is marked as unused.
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]