From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 5/6] compress: add the core file Date: Tue, 29 Nov 2011 08:21:56 +0100 Message-ID: References: <1314943585-11670-1-git-send-email-vinod.koul@linux.intel.com> <1321951920-4363-6-git-send-email-vinod.koul@linux.intel.com> <1322106354.1516.951.camel@vkoul-udesk3> <1322127157.1516.973.camel@vkoul-udesk3> 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 67AC710381C for ; Tue, 29 Nov 2011 08:22:00 +0100 (CET) In-Reply-To: <001201ccae15$c24d8bf0$46e8a3d0$@bossart@linux.intel.com> 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: Pierre-Louis Bossart Cc: 'Vinod Koul' , broonie@opensource.wolfsonmicro.com, alsa-devel@alsa-project.org, lrg@ti.com List-Id: alsa-devel@alsa-project.org At Mon, 28 Nov 2011 15:36:15 -0600, Pierre-Louis Bossart wrote: > > > > implementation? At least, the term "frame" is already used in ALSA > > > PCM, and I'm not sure whether you use this term for the very same > > > meaning in the above context... > > Most compressed formats have a notion of frame, but this is indeed a > different notion. In ALSA a frame is really a sampling point, possibly with > multiple channels. Compression algorithms group sampling points in frames, > or blocks, before applying a transform and quantizing. AAC works with 1024 > sampling points, MPEG Layer3 with 2 granules of 576 points, AMR with 160 > points, etc. > We may want to use terms like 'blocks' or 'chunks', if this helps avoid > confusions with existing ALSA concepts. Yes, it's better to avoid the conflicting definition, IMO. > > For capture, since application may need to get data on frame basis > > (think video recording with encoded video usage, where application > > needs > > audio compressed data on "frame" basis for encapsulation). The DSP is > > supposed callback after every encoded frame. I think only difference > > between PCM and this is encoding format, otherwise in terms of decoded > > data and time they would mean the same.. I am not expert here so maybe > > wrong. > > For capture, in some cases the compressed bitstream doesn't provide any > pointers on the beginning of a block, nor any block-length indication (eg. > AAC-RAW). In that case, an encoder would need to pass data to user-space on > a block-by-block basis, with the bytes available in the ring buffer > corresponding to the block length. If the applications can extract 'blocks' > on their own and handle the relevant file-write/multiplexing, the usual > data-passing with regular events is fine. > > For playback, the decoder is expected to deal with such situations on its > own and find the block boundaries, meaning at the application level we can > just push bytes down to the decoder without worrying. But is this restriction guaranteed to be applicable to all possible hardwares in future? What happens if you'll get a hardware that doesn't support the byte-unit push for the playback? That said, I see no obvious reason to give a restriction coupled with the stream direction. thanks, Takashi