[PATCH] ALSA: compress: allow pause and resume during draining

[Jaroslav Kysela]

Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a):
> On Tue, 29 Sep 2020 03:51:35 +0200,
> Gyeongtaek Lee wrote:
>>
>> On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote:
>>> On 9/28/20 6:13 AM, Jaroslav Kysela wrote:
>>>> Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a):
>>>>> With a stream with low bitrate, user can't pause or resume the stream
>>>>> near the end of the stream because current ALSA doesn't allow it.
>>>>> If the stream has very low bitrate enough to store whole stream into
>>>>> the buffer, user can't do anything except stop the stream and then
>>>>> restart it from the first.
>>>>> If pause and resume is allowed during draining, user experience can be
>>>>> enhanced.
>>>>
>>>> It seems that we need a new state to handle the pause + drain condition for
>>>> this case.
>>>>
>>>> With this proposed change, the pause state in drain is invisible.
>>>
>>> Indeed it's be much nicer to have a new state, e..g 
>>> SNDRV_PCM_STATE_DRAINING_PAUSED.
>> Ok. I will add the new state.
>>>
>>> One concern is that states are defined in uapi/sound/asoc.h, so wouldn't 
>>> this have impacts on userspace as well? We'd change the value of 
>>> SNDRV_PCM_STATE_LAST.
>>>
>> I also agree that adding new state and increase LAST value in the header of uapi
>> could be dangerous. So, I added it to comress_offload.h for now.
>> It could be merged into snd_pcm_state_t in someday with big changes.
>> Could you review the fixed patch below?

I don't see a big problem to improve the API, but don't forget to increase the
SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour.

> Hrm, this resulted in rather more complex changes than the original
> patch.  It shows that introducing yet another state is no good idea
> for this particular case.

I don't think so. The states should be isolated and it's clearly a new state
and the resulted code at least gives a commented idea, what's going on. It
seems that the compress driver state is not exported to the user space at the
moment, so I would consider this extension as harmless. We can add this state
to asound.h so the user space can be updated. We may use this state for the
standard PCM devices one day, too. It makes sense to reserve it sooner than later.

BTW: Offtopic - Why compress code returns EPERM if the state is not correct?
It's not about the permissions. The EBADFD is much better code in this case.

						Jaroslav

> 
> Since the possible application's behavior after this pause is as same
> as the normal pause (i.e. either resuming pause or dropping), I find
> it OK to take the original approach.
> 
> 
> thanks,
> 
> Takashi
-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.