[alsa-devel] [PATCH 5/6] compress: add the core file

[Nallasellan, Singaravelan]

> > Even the thread which actually writes the data to ring buffer may not
> > have the idea of frames So the start threshold does not require to be
> > on frame boundaries. It is just to avoid START when the buffer is
> > written with the data. If the write gives more data than the ring
> > buffer, write will not unblock and the user space application may not
> > be able to call START.
> > This will be an issue if you go for non-blocking implementation.
> > Otherwise, START should be called in another thread than the thread
> > which writes the data.
> 
> I did not understand a single line of this comment.
> Why is this start threshold needed again and how would its value be defined for
> compressed data?

I will try to explain it with more details. 

Consider the case of blocking "write" call:

If the user space app writes the buffer with the content of size greater than the 
ring buffer size, write call will block. How do you expect the user space to invoke START ioctl?
I assume the write call will block until it writes the complete content into the buffer. 

To avoid this behavior, the app has to query only the empty space and write only that much data.
Then it should call START.