[alsa-devel] [RFC] compress: add support for gapless playback

[Takashi Iwai]

At Wed, 6 Feb 2013 06:09:32 -0800,
Vinod Koul wrote:
> 
> On Wed, Feb 06, 2013 at 03:11:02PM +0100, Takashi Iwai wrote:
> > At Tue,  5 Feb 2013 06:21:25 -0800,
> > Vinod Koul wrote:
> > > 
> > > From: Jeeja KP <jeeja.kp at intel.com>
> > > 
> > > this add new API for sound compress to support gapless playback.
> > > As noted in Documentation change, we add API to send metadata of encoder and
> > > padding delay to DSP. Also add API for indicating EOF and switching to
> > > subsequent track
> > 
> > I can understand that the metadata is somehow handled in DSP for
> > seamless switching, 
> yes for stripping the encoder delay and encoder padding.
> > but the operation with partial drain is a bit
> > unclear.
> > How is the operation flow?  Does it drain until which point?
> Right, we want to move from one track to another. And while at this DSP needs to
> exhaust the buffers from first track and then we should start writing second
> track. When userspace has finsihed wirting first track it sends partial_drain
> and DSP decods finsihed off and returns when it is ready to accept second track
> data. The userland sends the metadata for this followed by data write.

Hm, could you depict the flow?  Will be like below?

- Open
- Get caps / codec caps
- Set params
- Set metadata of the first track
- Fill data of the first track
- Trigger START
- User-space finished sending all, then trigger PARTIAL_DRAIN
- Set metadata of the next track
- Fill data of the next track
....


> > In your patch, the runtime state is changed to SETUP after the partial
> > drain, so the app is requested to give START again?
> Ah, thats a mistake, it should be in running state, no START again :)

OK, then PARTIAL_DRAIN doesn't sound intuitive.
Something like CONTINUE_TO_NEXT?

(I'm not particularly good at naming, so someone must have a better
 idea...)


Takashi