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.
