Re: [LAD] how to store deferred events in a real time audio app?

On Mon, Dec 19, 2011 at 5:10 PM, Iain Duncan <iainduncanlists@email-addr-hiddenwrote:

> Anyone have any suggestions for how to safely do the above or some better
> alternative?
>

I will state my current implementation of such a feature, and let you
decided if its good / bad / ugly :D

enum TrackState {
  TRACK_STATE_NORMAL,
  TRACK_STATE_EVENT_QUEUED,
  TRACK_STATE_EVENT_NOW,
};

process()
{
  if ( state == TRACK_STATE_EVENT_QUEUED && time == topOfTrack )
    processQueuedEvent();
  else if ( state == TRACK_STATE_EVENT_NOW )
    processNowEvent();
   // process your MIDI output or whatever your doing..
}

I'm storing all the "events" in a ringbuffer that another thread can write
to, so say GUI stuff all gets updated trough "Event::setX()" style
functions, and then they're read "raw" on the other side (public member
variables..) its not strictly OOP, but I don't want to write the 30+
functions & structs* to pass back exactly what is expected every time :)

I think its a pretty OK way of going, each track will have a "TrackState"
variable, and that tells you everything you need about the track. Of course
if you want to have multiple things like playing - paused - relocating, as
well as normal - queued - now, then you should convert them to bitfields,
or separate enums to keep yourself sane...

I've just the one, but my "BufferAudioSource" doesn't have that many states
that can be active at the same time, so I've just kept it like above.
Simple :)
HTH, -Harry

PS: Re RT-ness, enum's are just ints, so its a RT safe & cheap.
PSS: Perhaps you could elaborate on what these "Events" could be, like just
a single event per track, or are we talking hundreds?

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Dec 20 04:15:04 2011