4 Apr
2003
4 Apr
'03
8:39 a.m.
On Thu, Apr 03, 2003 at 03:14:53PM -0500, rm wrote:
On Thu, Apr 03, 2003 at 11:31:29AM -0800, Tim Hockin
wrote:
hmmm i noticed after i posted that it said, "we will be adding". so
it's not there yet, but it will be eventually. there are examples of
no it is not there.
the current code uses mutex_lock and and a condition.
courtesy
of paul davis:
you should use a lock free ringbuffer. we will be adding example code
to the example-clients directory soon. existing code is in ardour's
source base (for C++). the example code will be in
example-clients/capture_client.c.
where ardour is ardour.sf.net. (i doubt there is anything hugely non-C in
the ringbuffer code proper).
maybe it's just me, but I can't find said file...? it in the ardour code though.
try looking at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ardour/ardour/libs/pbd/ringb…
ie ( ardour/libs/pbd/ringbuffer.cc ) in the source distribution.
click on the rev 1.2 (view) link.
The problem i have with the current ringbuffer, is that it does not
solve the synchronization of the non realtime thread to the realtime
thread. what should be done when you cant write to the buffer ?
usleep( a_sensible_value ); ?
wouldnt it be nicer to wakeup the non realtime thread with a condition ?
the galan ogg-reader starts a reader thread and two gasync queues...
then i have 2
struct buffer { SAMPLETIME timestamp; SAMPLE buffer[SIZE]; } *
which are passed between the reader and the realtime thread;
reader fills in buffer and realtime fills in the timestamp, so the
reader thread knows where it should read next.
this implementation is just the same as the current capture_client in
jack.
(note that the mlock/unlock stuff is for locking the buffer region
into memory).
below is what i use (i think it works). the primary thing to notice
is that readers and writers are kept in line by the atomicity of
integer assignment (though in general, we should probably declare them
atomic_t or something).
yeah... that is the principle of the lock free ringbuffer.
another thing to note is that this allows one writer and one reader to
communicate asynchronously in one direction (where one writer and one
reader may be a group of writers and readers who are synchronous with
respect to their group members). the important thing is that one group
must always be the writers and one group must always be the readers
and they may not switch at any time.
but how is synchronisation done ?
this is my main problem with it.
the problem with gasync queue is that a queue is not a threadsafe
data structure. so it should be possible to modify the gasync queue to
have a ringbuffer instead of a queue and then only use a mutex for the
condition signaling. g_cond_signal can be called without holding the
mutex so that should be ok for this case.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language