Subject: Re: [linux-audio-dev] buffering, latency, cut-outs
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to tammi 13 2000 - 16:44:26 EST
>OK, that makes sense. But then it seems to me that I need mutexes on
>all the objects which the GUI might change, and then the audio thread
>can once again become delayed by the GUI thread (but perhaps not as
>badly). Is that true? (I have a fair amount of experience with threads
>in Java but none in C.)
Very few X toolkits (including GTK) are inherently thread safe. GTK
can be used in a thread-safe fashion in one of two ways. I use the
more efficient-for-real-time-apps method, but it involves more
code. There is only 1 thread that ever gets to talk directly to
GTK. It has a pipe that receives structured messages from other
threads asking it do things. Its a design that I have become very
comfortable with, to the point of now having a "Gtk_UI" C++ object
that bundles all this up for reuse. Basically, if a thread is not the
GUI thread, it doesn't do anything with the GUI toolkit at all.
But yes, things do get more complex. No question about that.
>256Mb (with a fair amount of stuff running--it's my work dev box so it
>has X, xemacs, netscape, mysql, apache, vmware, etc.) But 16K of
>buffer is like 350 microseconds and that seems unusually bad.
How do you compute that ? What sample rate are you running at, or
rather and/or how many channels ? 16K of 44.1/16-bit stereo is close
to 1 second by my calculations.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST