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.
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. -Pierre