Re: [gtkmm] new thread vs. fork to play a sound on button press

[Daniel Elstner <daniel elstner gmx net>]

(Note: please do always cc the list)

On Don, 2002-12-26 at 10:44, Mark Jones wrote:
> At 04:49 AM 12/26/2002 +0100, you wrote:
> >This strikes me as odd.  I never used esd_play_file(), but isn't it the
> >point of esd to send the playback request to a sound server and forget
> >about it?
> 
> Well, I'm not sure if I fooled myself at one point or not, but I thought it 
> was waiting for it to finish, but later I realized it has a huge latency 
> problem and so my 2nd sound might have just been delayed, rather than the 
> 1st call not completing.  I don't recall if I had any debug output in at 
> that point.  But, due to the latency issues I'm looking at libarts.  Since 
> gnome does not use libarts, the server is not started automatically so I'm 
> not sure what I'll do about that.  With esound development appearing to be 
> stalled and from snippets I read about it compared to libarts tonight, I 
> wonder if gnome will move to libarts or not.

It's more likely that GNOME will use the gstreamer framework for
everything multimedia-related in future.

> I realized that to get the lowest latency, I probably need to use pthreads 
> directly, because that should be faster than anything wrapping it, and 
> faster than a fork too.  At least I hope.

You're clearly overestimating the performance penalty of a wrapper
layer.  Creating new threads is expensive enough to render the overhead
of a few function calls absolutely irrelevant.

> If libarts proves to have a 
> super low latency, I might try moving up to glibmm and see if I still get 
> the required response time.  I didn't see many examples for glibmm, like a 
> tutorial either and I didn't want to take the time tonight to figure it 
> out, but I might later.

See examples/thread/ in the tarball.  The interface is very similar to
POSIX threads (just a bit more C++'ish).  If you know how to use phtread
you also know how to use glibmm threads.

--Daniel