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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Iain Duncan <iainduncanlists@...>
Cc: <linux-audio-dev@...>
Date: Tuesday, December 20, 2011 - 1:34 am

--20cf30051540a68ffa04b47c0fb6
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 19, 2011 at 5:10 PM, Iain Duncan wrote:

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

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?

--20cf30051540a68ffa04b47c0fb6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 19, 2011 at 5:10 PM, Iain Duncan <iainduncanl=
ists@gmail.com
> wrote:

Anyone have any suggestions for how to safely do the above or some better a=
lternative?I will state my current implementati=
on of such a feature, and let you decided if its good / bad / ugly :D
enum TrackState {=A0 TRACK_STATE_NORMAL,=A0 TRACK_STATE_EVENT_Q=
UEUED,=A0 TRACK_STATE_EVENT_NOW,};process(){=A0 if =
( state =3D=3D TRACK_STATE_EVENT_QUEUED && time =3D=3D topOfTrack )=
=A0=A0=A0 processQueuedEvent();
=A0 else if ( state =3D=3D TRACK_STATE_EVENT_NOW )=A0=A0=A0 processNowE=
vent();=A0=A0 // process your MIDI output or whatever your doing.. =
}I'm storing all the "events" in a ringbuffer that an=
other thread can write to, so say GUI stuff all gets updated trough "E=
vent::setX()" style functions, and then they're read "raw&quo=
t; 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 exa=
ctly what is expected every time :)
I think its a pretty OK way of going, each track will have a "Trac=
kState" variable, and that tells you everything you need about the tra=
ck. Of course if you want to have multiple things like playing - paused - r=
elocating, as well as normal - queued - now, then you should convert them t=
o 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 jus=
t kept it like above. Simple :)HTH, -HarryPS: Re RT-ness, enum&=
#39;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? =

--20cf30051540a68ffa04b47c0fb6--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] how to store deferred events in a real time audio ..., Harry van Haaren, (Tue Dec 20, 1:34 am)