[alsa-devel] [RFC] G.723-24 format patch

[Takashi Iwai]

At Mon, 10 May 2010 13:50:26 -0400,
Ben Collins wrote:
> 
> On Sat, 2010-05-08 at 11:58 +0200, Takashi Iwai wrote:
> > At Sat, 01 May 2010 11:36:03 -0400,
> > Ben Collins wrote:
> > > 
> > > I'm writing a driver for a card that only has hardware support for
> > > G.723-24 ADPCM format. I am working around the lack of support in alsa
> > > at the moment for this format, but wanted to take a crack at
> > > implementing it properly.
> > > 
> > > G.723-24 is a 3-bit signed sample at a fixed 8khz mono sample rate
> > > (24000 bit rate). Basically means you need to take in at least 3 bytes
> > > (8 samples) minimum for processing the standard packed version.
> > > 
> > > I don't have hardware that supports it, but since I was in the code, I
> > > added a G723_24_1B format for producing 1 sample per byte (3 lower bits
> > > are actual sample), but for my use I am producing the standard packed
> > > stream.
> > > 
> > > Only question I had is that since this is signed, should I expect or
> > > want the _1B version to be a 1 byte sign extended version of the 3-bit
> > > sample, or just expect the lower 3 bits of the byte to be the g723-24
> > > sample? Looking at other unpacked examples, I assume the latter rather
> > > than the former.
> > 
> > I suppose both are non-linear formats, so you shouldn't give
> > signed/unsigned flags for them.  Otherwise snd_pcm_format_linear()
> > will return 1.
> > 
> > Other than that, addition of these new formats look good to me.
> 
> I may not be understanding the implications of setting them as
> signed/unsigned. G.723 decoder treats each sample as signed. Does
> alsa-lib do special things when it is signed even though it doesn't
> understand the actual encoding?

The signed/unsigned information is useful only for linear PCM formats
(e.g. U8, S16, etc), so that they can be converted with each other
simply with bit shift and sign-bit flip.  Non-linear formats
(e.g. ADPCM, ulaw, etc) require specific conversions, thus its
conversion to other formats isn't supported always in the kernel, and
signed/unsigned information isn't referred as well.

Similarly, in alsa-lib, signed/unsigned information doesn't give much
merit but for linear PCM formats.


thanks,

Takashi