[Stk] STK and OpenGL

[Stephen Sinclair]

Well,

On Fri, Nov 7, 2008 at 5:12 PM, Schell <efsubenovex at gmail.com> wrote:
> I am talking about having an audio callback playing real-time audio with a
> separate graphics process drawing to the screen. Thanks for helping me. I
> figured out my problem, it was as simple as moving on to the next tutorial
> and using a callback. That fixed it. The next step is to hold all the
> samples to be fed to the callback buffer in a separate buffer so the
> graphics loop can access it. I'm really just getting used to multimedia in
> c++, I'm used to working with AS3 which is all event based and asynchronous,
> where c is very procedural. My understanding [or lack thereof] of a c
> program's structure isn't quite tuned right.

Fair enough.


> For the future, if I am going to need threading, could you point me to those
> single-read, single-write circular buffer examples? I know google is my
> friend, but it doesn't exactly tell me what's the best example, just the
> most found.

For what it's worth, I've found that it's often better to use
processes instead of threads, and send data between them using a
socket connection, using Open Sound Control for example.  You can use
non-blocking reads in the audio callback to accept data over a network
connection.

But anyways, in some cases it does make sense to use a threaded model.
 There's a circular buffer (sometimes called ring buffer) in many
audio libraries.  JACK has one, so does PortAudio it seems:

http://www.portaudio.com/docs/v19-doxydocs/pa__ringbuffer_8h.html

Another example, I have a class in my haptics software (DIMPLE) called
CircBufferNoLock, which I ported to C++ from some FIFO code in the
Linux kernel.  That is available at
http://www.idmil.org/software/dimple

The basic idea is that if you have a read pointer and write pointer
into a circular buffer, you can increase locations of the two pointers
independently and concurrently without creating a situation in which
either one is invalid at any given time.  So in your GUI thread you
write data to it if there is room left, otherwise you wait.  In your
audio thread, you read data from it, unless there is none, in which
case you continue without blocking.  This way you can safely pass data
between the two threads.  The data can be actual audio information, or
could be pointers to data structures to inform the algorithm, for
example.

There has been a pretty detailed discussion of this topic on the Linux
Audio Developer's mailing list recently, you could read that if you're
interested: http://www.linuxaudio.org/mailarchive/lad/149338/search/subject

I dunno, it can get very technical; I find a good strategy is to just
treat threads the same as processes and use sockets or some other IPC
mechanism to talk between them.  As long as you can do it in a
non-blocking manner (for the audio side) you should be fine.  These
days I've been often implementing the audio side of things in a higher
level language like ChucK or PureData anyways, since it seems to
simplify a lot of this stuff.


Steve