On Thu, 31 Oct 2024 17:12:53 +0100,
Jarosław Janik wrote:
>
> On 31.10.2024 10:15, Takashi Iwai wrote:
>
> > Per reading the patch description, though, the behavior appears to be
> > pretty unreliable, as it depends on the runtime suspend. We may
> > control the runtime PM better if we know that the beep must be
> > submitted; or it's even possible to runtime resume/re-suspend upon
> > beeping, too. But it's maybe too complex than needed.
>
> You must have misunderstood that, this unreliable behavior is what
> happens with your patch applied, once this patch is reverted everything
> works perfectly fine (again). Perhaps the commit message should be
> rewritten to indicate it more clearly, e.g. replace:
> > now those beeps are either muted altogether
> with
> > since 4f61c8fe3520 those beeps are either muted altogether
>
> ... or perhaps it should be just left as it is...
Hm, so the beep works even if the HD-audio device is runtime-suspended
before shutdown? Also, beeping at suspend/resume works no matter
whether runtime-suspended or not?
thanks,
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]