[LAD] PHASEX-0.10.2

William Weston weston at sysex.net
Thu May 24 10:09:03 UTC 2007


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.

--ww




More information about the Linux-audio-dev mailing list