[alsa-devel] [RFC 4/5] compress: add the core file

[Mark Brown]

On Sat, Sep 03, 2011 at 08:36:25AM +0530, Vinod Koul wrote:
> On Fri, 2011-09-02 at 15:36 +0100, Mark Brown wrote:
> > On Fri, Sep 02, 2011 at 11:36:24AM +0530, Vinod Koul wrote:

> > > + *   TBD how the cpu dai will be viewed and started.
> > > + *	ASoC should always be optional part
> > > + *	(we should be able to use this framework in non asoc systems

> > Just write an ALSA core API, ASoC is an ALSA driver so it can just use
> > the same interfaces as everything else gets.

> Actually no. That way devices would get regsitered as /dev/snd_pcmCxDxy
> which wont be corect.

I'm sorry, I can't understand why this would be the case?  ALSA already
has devices with several different names (control, hw, and pcm).

> > > +	runtime->state = SNDRV_PCM_STATE_OPEN;
> > > +	init_waitqueue_head(&runtime->sleep);
> > > +	data->stream.runtime = runtime;
> > > +	f->private_data = (void *)data;

> > Should we hoist these before we call open(), especially the init of
> > runtime?  It seems likely to be more robusy.

> Since open is just supposed to let the device know that stream is being
> created with a particular direction. Event if I move this up, doesn't
> serve a purpose as driver should touch these a t open.
> But I agree this helps to make more robust 

The most obvious ones were the runtime pointer and the state, I can
easily see some configuration being done on init that might also be done
at later and so want to check the state.

> Well I kept them placeholder to remind me what else needs
> implementation, I think I will keep them for a while as we need to
> implement mmap and recording support as well. Recording is actually
> trivial after playback.

It's generally preferred to omit this sort of stuff from actual
upstream submissions.

> > > +EXPORT_SYMBOL_GPL(snd_compr_period_elapsed);

> > I can see why you picked period_elapsed() (for consistency) but it feels
> > wrong to have a time based name for something which is going to end up
> > being data size based.

> Yes the notion of period here cannot be time it is in bytes.

Right, but the trouble is that "period" generally means a unit of time
so it doesn't read right.