[alsa-devel] RFC: PCM extra attributes

Takashi Iwai tiwai at suse.de
Fri Jun 19 11:11:54 CEST 2009


At Fri, 19 Jun 2009 10:47:30 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Fri, 19 Jun 2009, Takashi Iwai wrote:
> 
> > Hi,
> >
> > this is yet another topic I'm (currently) working on -- the addition
> > of PCM ioctls to get/set some extra attributes.  Basically, it adds
> > two simple ioctls for getting/setting extra attributes to the PCM
> > substream.  The attribute has a sort of TLV form,
> >
> >  /* PCM extra attributes */
> >  struct snd_pcm_attr {
> >  	unsigned int type;	/* SNDRC_PCM_TYPE_ATTR_XXX */
> >  	unsigned int len;	/* GET R: the max elements in value array
> >  				 *     W: the actually written # elements
> >  				 * SET R/W: # elements to store
> >  				 */
> >  	unsigned int value[0];	/* value(s) to read / write */
> >  };
> >
> > And corresponding two ioctls
> >  #define SNDRV_PCM_IOCTL_GET_ATTR	_IOWR('A', 0x14, struct snd_pcm_attr)
> >  #define SNDRV_PCM_IOCTL_SET_ATTR	_IOWR('A', 0x15, struct snd_pcm_attr)
> 
> I would prefer to implement similar TLV implementation as for the control 
> API. The amount of information for reading (get) will be small, so 
> filtering in this direction is not necessary. Also, common parts of 
> implementation (future merging of more TLVs to compounds) can be shared.

Actually it's a sort of TLV.  You see exactly it in snd_pcm_attr
struct, no? :)

And, thinking twice after posting (that's a good effect of posting to
ML, BTW), I feel that using a callback would be a better way, such as
re-using the existing ops->ioctl with a new cmd tag rather than the
statically assigned thing. 

A similar method like control TLV can be used, too.  However, a
distinct from the existing control TLV is that this is intended for
just one type of information while the control TLV is supposed to
contain everything in a single shot.

That is, this is a query with a key.  In that sense, sharing a small
amount of control TLV code (about 10 lines) doesn't give a big
benefit.  In anyways, it's a implementation detail, so one could
optimize somehow, though...


thanks,

Takashi


More information about the Alsa-devel mailing list