[alsa-devel] [PATCH 5/6] compress: add the core file

[Takashi Iwai]

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