[alsa-devel] [RFC] compress: add support for gapless playback
tiwai at suse.de
Wed Feb 6 15:48:26 CET 2013
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?
- 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
More information about the Alsa-devel