Marcel,

Before making the changes you suggested, I did a little testing with the debugger. Turns out my method is just fine for creating signals from other threads. In each case that I called one of the public functions in my GUI class to emit the signal, when the GUI update was actually performed it was in fact performed by the GUI thread, not the thread that called the public function causing the signal to be emitted. This was verified in both Windows and Linux.

I further verified this fact with Trolltech. They stated: "because when the signal is emitted the code in the QMetaObject::activate() will check that the thread that resulted in the emission of the signal is different from the thread in which the object lives. If this is the case, an event will be posted to the event loop of the receiver and will be be processed asynchronously so this is safe."

In any event, I'm back to square one. I rewrote my ALSA routines to be separate threads (one for playback and one for record) that use blocking calls to move the data. Excactly the same external interface to the rest of my application. No GUI lockups now. Even more surprising is that the audio performance and latency is much better.

At this point, I'm going to put this on the back burner and expect I'll find the root cause at some point while doing something else. If I do, I'll post on it.

Thanks for all the suggestions, I certainly learned a lot about some things I didn't know much about before.

Regards,
Doug