On Thu, 2007-05-24 at 03:09 -0700, William Weston wrote: > On Thu, 24 May 2007, Lars Luthman wrote: > > > On Thu, 2007-05-24 at 00:56 -0700, William Weston wrote: > > > On Wed, 23 May 2007, pete shorthose wrote: > > > > > > > On Tue, 2007-05-22 at 16:21 -0700, William Weston wrote: > > > > > I'll be looking into the patch loading issue next. From what I can > > > > > tell, the first access of the File menu (either by hitting it > > > > > directly or accessing an item through a keyboard acceleration) > > > > > causes enough of a CPU hit to disrupt other threads. This is the > > > > > only menu that currently uses the GTK stock items and keyboard > > > > > accelerations. Any GTK hackers out there have any tricks for making > > > > > sure a GtkAccelGroup has fully initialized itself? > > > > > > > > do you have a specific reason to lay blame on the accel group? > > > > more than say, the open dialog? > > > > > > This reasoning was based on the fact that only the file menu uses > > > accelerators, and only the file menu experienced the delay (and only > > > on the first access), whether accessed by clicking with the mouse or > > > using a keyboard accelerator. The first access of the file menu > > > would cause JACK xruns about half the time, while opening a file > > > dialog after the file menu has already been accesed would not cause > > > xruns. > > > > xruns? The GUI should _never_ be able to affect the audio thread's > > performance. Aren't you running JACK in realtime mode? > > Yup, I'm running JACK with realtime scheduling, and I had exactly > the same thought. The GUI is running at a normal SCHED_OTHER > priority, and it holds no absolutely no locks needed by other > threads after everything is up and running.
What kernel is this? Are you using Ingo Molnar's RT patch? --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
