From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: more sample formats? too little place left. Date: Tue, 04 Jun 2002 13:26:17 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Dan Hollis Cc: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Mon, 3 Jun 2002 14:32:43 -0700 (PDT), Dan Hollis wrote: > > On Mon, 3 Jun 2002, Takashi Iwai wrote: > > but the question is whether we should just add such new formats as new > > bits, or define something more ordinary. > > A format descriptor structure, instead of hardcoded format types? > > 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(). 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. 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