At Tue, 29 Nov 2011 15:15:01 -0600, Pierre-Louis Bossart wrote:
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.
Power consumption will be more optimized if we push bytes without looking for block boundaries on the host. But if your hardware requires parsing on the host, there's no impact on the API. You'd just write block-by-block and specify the block length instead of fixed-size value.
Well, my question is much more simple. In the patch, there are checks of the stream direction in snd_compr_{fragment|frame}_elapsed() functions.
+void snd_compr_fragment_elapsed(struct snd_compr_stream *stream) +{ + pr_debug("fragment elapsed called\n"); + if (stream->direction != SNDRV_DEVICE_TYPE_COMPR_PLAYBACK) + return; + wake_up(&stream->runtime->sleep); +} +EXPORT_SYMBOL_GPL(snd_compr_fragment_elapsed); + +void snd_compr_frame_elapsed(struct snd_compr_stream *stream) +{ + if (stream->direction != SNDRV_DEVICE_TYPE_COMPR_CAPTURE) + return; + wake_up(&stream->runtime->sleep); +} +EXPORT_SYMBOL_GPL(snd_compr_frame_elapsed);
And I wonder why this restriction *must* be present in the API-level implementation.
And, furthermore, I see no reason to have this individual functions. Why simply not an inline function like
static inline void snd_compr_stream_elapsed(struct snd_compr_stream *stream) { wake_up(&stream->runtime->sleep); }
?? Then you can reduce two exported symbols and less stack usages.
Takashi