Subject: Re: [linux-audio-dev] discussion about development overlap
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Sep 29 2000 - 20:03:16 EEST
On Thu, 28 Sep 2000, Kai Vehmanen wrote:
> On Thu, 28 Sep 2000, Benno Senoner wrote:
>
> > How do you manage audio<-->GUI and audio<-->diskthread
> > communicaion ?
>
> I'll bump in here. :) Currently I do this using a pthread-locked fifo,
> which is used for all communication with the engine process. Ok, I know
> this has been discussed already, but how much trouble should I expect
> (portability wise), if I replace the current fifo with an non-locking fifo
> using asm/atomic.h? In other words, is it worth the trouble to keep both,
> and write autoconf macros that check for asm/atomic.h...? And the natural
> next question, has someone already done this? :)
>
It's quite easy IMHO:
just use a ringbuffer.h-like structure ,
define your message structure ( typedef struct { bla bla bla } mymsg_t; )
and then instantiate a ringbuffer class with this type
(this works for C++, for plain C you have to provide functions where you
pass your msgtype as void with the type's size, so that the code knows
how many bytes to copy / how many bytes to advance the ptrs etc)
Basically you need to setup a finite queue size
(use a reasonably large one), and the audio thread simply polls for commands
at each audio fragment, and/or sends commands via this fifo, but it never
blocks.
If you ask me, I'd keep only the lock-free fifo, even if you do not exploit its
full advantages (that it does not block and that it is very fast).
But if you write in C, one has first to write the routines which permits reading
and writing to the fifo.
I think the best would be to convert the ringbuffer.h stuff to C,
but EVO's version of this file is a bit modified, because of the buffer wrapping
and extra allocated bytes. It should be easy though to remove that stuff.
Benno.
This archive was generated by hypermail 2b28 : Fri Sep 29 2000 - 18:54:40 EEST