Re: more sample formats? too little place left.

[Takashi Iwai <tiwai@suse.de>]

At Tue, 4 Jun 2002 13:55:54 -0700 (PDT),
Dan Hollis wrote:
> 
> On Tue, 4 Jun 2002, Takashi Iwai wrote:
> > > Of course you will want a good API support structure for handling format 
> > > conversions...
> > hmm, i don't think it must be a struct.  enum (int) could have enough
> > values if it's not bitmask, although the order of format enumerators
> > may look a bit weird.  there are already functions to retrieve a
> > detail information from the format type enum, such as
> > snd_pcm_format_width() and snd_pcm_format_little_endian().
> 
> we want something expandable but avoid ugliness. something that jaroslav 
> has been very good at so far (with switches, etc)
> 
> 65535 different formats should be enough :-) and if there are functions to 
> provide detailed descriptions of the formats, i think it's a good 
> solution. even if the order of the formats looks strange because more are 
> added on later.
> 
> > so far, the bitmask is used only inside the alsa-driver and alsa-lib.
> > they must be extended in some good way.  i believe that this change
> > can be hidden without changing API itself, but not figure out how
> > should we do that yet.
> 
> and do it right the first time :-)

i talked (yes, physically!) with Jaroslav about this issue.
our conclusion is to extend the snd_pcm_hw_constraints_t struct,
namely, using char arrays instead of int for mask bits.
this will require an update of alsa-lib, too.  the old alsa-lib
won't run.  but applications are not necessarily compiled.
the other things should be kept as they were.
the order is ugly, but they are mostly exceptional cases.
we don't want to break compatibility on this stage.

i think this change can slip into rc2 (hopefully).


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink