Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon May 07 2001 - 16:51:07 EEST
>I try to redraw my example using your graphic conventions:
>
>
> GUI visual scope
>+------||-----------||-------------------------------------+
>| audio_producer1 ----\ |
>| audio_producer2 -----\ /-- audio_consumer1 |
>| > engine < |
>| audio_producer3 -----/ \-- audio_consumerN |
>| audio_producerN ----/ |
>+-------||-----------------------------------||------------+
> appl file writer thread
>
>Now, let's zoom on audio_producer1:
>
> GUI visual scope
> || ||
> ------------------||--------||-------
> || ||
> HW capture -> plugin -> meter ->
First problem: "HW capture"
The entire point of the LAAGA API is to remove such
concepts from the things that use LAAGA. The LAAGA
server is the only thing with access to the H/W, and the
only thing that cares about hardware.
Now, this can be avoided by saying "oh, by "HW capture"
I just mean something like "read_from_channel (chn, ...)",
and thats OK.
Except that ALSA has no component in its API that looks
anything like this, and if it did, its semantics would
be rather hard to specify, since it would presumably
have to work both within a system like LAAGA and without.
It makes sense in LAAGA to have "read_from_channel(chn,...)"
since that function is always called from "interrupt"
context (i.e. on return from poll(2)), and we can call
it for many different channels without blocking etc.
But what would such a function do in a non-LAAGA application?
>Zoom on audio_producer2:
>
> GUI
> ||
> ------------||----
> ||
> file -> plugin ->
if i understand this correctly, it would violate the rule on no
blocking operations in server plugins.
>Zoom on audio_producer3:
>
> appl -> pcm_lbserver
> ||
> -----||--------------
> ||
> pcm_shm ->
looks good.
>Zoom on audio_consumer1:
>
> -> pcm_file_writer -> HW playback
> ||
>-----------||-------------------------
> ||
> File writer thread
same problems as with "HW capture", but substitute
"write_to_channel".
Finally, i would echo Jim's broader point about this model of
"producers and consumers". Most of the kinds of things that would be
attached to this server would be both producers and consumers, and its
hard for me to see how (or even why) to use this kind of model if that
kind of plugin dominates.
--p
This archive was generated by hypermail 2b28 : Mon May 07 2001 - 17:12:18 EEST