Subject: [linux-audio-dev] Merging events from multiple senders (was: MidiShare Linux)
From: David Olofson (david_AT_gardena.net)
Date: Fri Jul 21 2000 - 17:12:43 EEST
On Thu, 20 Jul 2000, Benno Senoner wrote:
> > >let's say we always know the number of readers:
> > >each reader reads form the FIFO but does not increase the read pointer.
> > >reach reader (atomically) increases a member (count) of the dataset with was
> > >just read, and as soon as it reaches NUM_READERS we will increase the read
> > >pointer and reset to zero.
> >
> > So it means that all readers read the same element?
>
> yes, but I have not done any research on the multiple reader isse just
> brainstorming.
> I do not need multiple readers, I have only one reader and one writer.
BTW, this works great for MuCoS event ports between plugins and
applications (meaning that a single reader - single writer FIFO
eliminates the need for additional thread sync), except for one
thing: Plugins normally have only one input (for event processing
efficiency), so there *will be* multiple writers!
No big deal, really, because only one plugin at a time can be
running, and the IPC isn't using the raw plugin API directly.
Besides, events need to be sorted before a plugin gets to read them!
(Or rather, sample accurate plugins will probably never care for the
option to receive unsorted events...)
Now, that's what I was thinking about; sorting events. I can see two
ways of doing it;
1) Sort when inserting the events
+ Quite easy to implement
- The macros to add events will have to do this inline, or there
will be a *terrible* amount of function calls...
2) Set up a "dummy" event list for each sender (*), and let the host
do the sorting when merging the event lists together for moving to
the real target port.
(*) Actually, the average host would only need one extra list, as it
can just deal with the events some time before some other plugin
needs to write to the same port.
Actually, 2) doesn't seem all that different from 1), but it's a way
nicer and more flexible design! Sorting can be done when inserting
the events in about the same way as for 1), if that turns out to be
the fastest way.
So, to the point with this post: Any more ideas on how to do this?
Any overhead hurts, but hey, the alternative is to run plugins with
variable buffer sizes, having the host keep track of when to stop for
event processing. And that still doesn't allow subsample accuracy...
> PS: just for cursiousity, does windoze provide atomic functions to
userspace > apps ?
Yes. The usual set, as any preemptive multitasking OS pretty much has
to do.
(Well, it can't be *infinitely* worthless, although one starts to
wonder at times...! ;-)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Fri Jul 21 2000 - 20:46:32 EEST