From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC] G.723-24 format patch Date: Mon, 10 May 2010 22:58:01 +0200 Message-ID: References: <1272728163.4822.31.camel@maclara> <1273513826.4325.4.camel@maclara> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id BEBF524886 for ; Mon, 10 May 2010 22:58:01 +0200 (CEST) In-Reply-To: <1273513826.4325.4.camel@maclara> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Ben Collins Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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