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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>>>> 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.
>>>>
>>>> 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.
>>> Thank you for the review.
>>> I think that I should resend the original patch.
>>
>> Let's wait a bit for other opinions.  We may add rather a new flag
>> instead of introducing a new state, too, for example.
> 
> I was out for a week, back now ;-)
> 
> So bigger question is if kernel should handle this change or we ask
> userspace to handle this. Userland knows that bit rate is less so small
> buffer can be for longer duration so instead of sending dumb X bytes,
> should it not scale the buffer based on bit rate?

what about variable bit-rate? or cases where you have a 'bit reservoir' 
in previous frames?

You really cannot in general translate bytes to time with compressed 
data, which is the reason we introduced the API in the first place...

Userspace *may* know the duration for specific formats or based on 
metadata, but in some cases the only way to know is actually to decode 
the data.

I suggest we keep the compressed API based on bytes and non-periodic 
events when the bytes were consumed/generated.