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