Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue May 08 2001 - 10:25:19 EEST
Paul Davis wrote:
> >for each producer
> > producer->wait()
>
> how can producer->wait() work ? things are supposed to be
> running in perfect sync, so what is it waiting for? is it the same
> thing that every other producer is waiting for ? is it the same thing
> that every consumer is waiting for?
No.
a diskstream consumer/producer is waiting to have enough available (here
I mean available from the engine point of view) frames in its buffer
an HW PCM is waiting to have enough availabe frames
>
> the point about "totally synchronous operation" is that its defined by
> the audio stream handled by the audio interface. when we say that
> we're ready for the "producers" to "get" and the "consumers" to "put",
> then to me this implies only one thing: there are "nframes" of
> data/space available to move audio data from/to the audio
> interface. as soon as you try to split this up into two different
> "waits", its very hard to enforce that this condition is being met.
This need to be separated. Conditions may be different and we need to
satisfy all to proceed (think for an HW PCM producer and a diskstream
producer).
> >However this is not the point (interleaved vs non-interleaved): I've
> >asked why you're interested to access channel separately.
>
> because in a non-interleaved situation, the data for each channel is
> computed separately, and if we cannot deliver it to the relevant
> channel as soon as its computed, we instead have to buffer it in some
> intermediate location (i'm assuming optimized code here, that reuses a
> buffer space in order to reduce cache misses; such operation should be
> considered normal by the kinds of apps we're interested in).
>
> i consider this wasteful. i believe that an elegant API lets me
> deliver the data to each channel once its ready, and then notify that
> I'm done with all channels (either implicitly, by return() or
> explicitly e.g. snd_pcm_mmap_commit()) . The ALSA PCM API (via mmap)
> lets me do this.
This is exactly what I mean: an audio component will know its source
buffers and destination buffers and then it will fill the channels it's
interested in.
Like in ALSA PCM API, where we have no function separated by channel.
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Tue May 08 2001 - 11:27:41 EEST