Jim Peters wrote:
> 
> Abramo Bagnara wrote:
> > I think there is some misunderstanding, the solution I proposed for
> > single thread audio engine is the following:
> >
> >
> >  audio_producer1 ----\
> >
> >  audio_producer2 -----\          /-- audio_consumer1
> >                        > engine <
> >  audio_producer3 -----/          \-- audio_consumerN
> >
> >  audio_producerN ----/
> 
> I can't make sense of this, because for me the server engine is BIG,
> enclosing all the producers and consumers, which talk amongst
> themselves inside it:

Just think to my -----> as functional link (all the things I've drawn
are in the same process) using ALSA PCM API, and then you get what
you've drawn (if I assume that +---+
                               |   |
                               +---+ is the process boundary).

> 
>                    (GUI for a plugin)   (ALSA pcm_shm interface to
>                            ||                  ||   some other process)
> +--------------------------||------------------||----------------+
> |  ENGINE, containing:                (more plugins)             |
> |                                        |                       |
> |  [HW input via ALSA] -> [plugin] -> [plugin] -> (whatever)     |
> |                            |           |                       |
> |             [plugin] <- [plugin] -> [plugin]                   |
> |                |                                               |
> |             (whatever)                 -> [HW output via ALSA] |
> |                                                                |
> +-----||------------------------||-------------------------------+
>       ||                        ||
>   (GUI for a plugin)      (GUI for a plugin)

But with some differences:

-  you assume that plugin chain is something that engine need to know
statically, while I say that engine get audio from zero or more producer
and put audio to zero or more consumer independently from what is hidden
behing them.
- a related difference is that you put at extremity two hardware while I
say that's not necessarily true.

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

Zoom on audio_producer2:

             GUI
             ||
 ------------||----
             ||  
   file -> plugin ->


Zoom on audio_producer3:

    appl -> pcm_lbserver
      ||
 -----||--------------
      ||
   pcm_shm ->

Zoom on audio_consumer1:

  -> pcm_file_writer -> HW playback
           ||
-----------||-------------------------
           ||
    File writer thread

All is limited only by your fantasy and mips available ;-)

-- 
Abramo Bagnara                       mailto:[EMAIL PROTECTED]

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Reply via email to