Re: [PATCH] ALSA: pcm: Release paused streams before suspend if resume is not supported

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 08/04/2025 11:51, Jaroslav Kysela wrote:
>>>          bool no_device_suspend; /* don't invoke device PM suspend */
>>> +       bool do_suspend_and_resume_in_pause; /* allow direct PAUSED ->
>>> SUSPENDED and
>>> +                                               SUSPENDED -> PAUSED
>>> transitions */
>>
>> I think the issue is bit different than this.
>> What needs to be flagged is that the driver is not treating the PAUSE
>> trigger in the same way as it treats the STOP or SUSPEND, in other
>> worlds, the PAUSED state is not equal to STOPPED/SUSPENDED.
>>
>> If the PAUSED state is equal to SUSPENDED state, then the trigger could
>> be skipped (as it is ignored before my patch unconditionally), but if
>> the two states are not equal then the SUSPEND must be sent, but the
>> patches from me and Takashi-san stil can be used as fallback in case the
>> RESUME is not supported as in that case the driver will certainly not
>> going to be able to resume to PAUSE_RESUME, so stopping a stream in that
>> case is appropriate.
> 
> The question is if the fallback is required when we had this issue for
> years.

This discussion is a proof that we might want.
We ended up disabling testing the suspend while paused case entirely for
quite some time and I could only get it working with my RFC attempt
before Takashi-san suggestion to do this in core level.

I agree that this is a rare corner case, more academic than not, users
will likely not going to face with as none of the audio servers use
pause so the chances that the system goes suspend while audio is paused
is close to zero.

> Using only a new trigger - to not release pause but directly do
> stop from the pause state - is acceptable for me. It should be easy to
> fix affected drivers. But on other side, the allowing state transitions
> (and even multiple triggers for finer driver notifications) may have
> also benefits for drivers.
> 
>> Side note: I think we might also have broken case when we stop a PAUSED
>> stream if the driver's PAUSED state is not equal to STOPPED/SUSPENDED.
>> It is just that applications never do this, at least I ave never seen a
>> missing STOP trigger. aplay is doing a pause release before stop at
>> least.
> 
> Aplay implementation is just about simplicity. The pause is handled in
> one routine which releases pause at the end. When the file descriptor is
> closed,
> snd_pcm_drop() is called and the pause is released there, too.
> Logically, it's not 100% correct thing. We know that we want to stop
> stream before the pause release is called.

The assumption is that PAUSED == STOPPED == SUSPENDED is not correct
either. This is not true for some drivers or devices.
I would go as far as to say that most drivers are mishandling the PAUSE
as stop, they likely cannot resume from the exact place where the pause
taken - they stop and if they have FIFO, they drop that as well...

> 
>                     Jaroslav
> 

-- 
Péter