[linux-audio-dev] Lock-free gtk/jack interaction

[Arnold Krille]

On Tuesday 15 March 2005 08:58, Olivier Guilyardi wrote:
> Arnold Krille wrote:
> >>My jackd manpage states that the default frames/period setting is 1024,
> >>which means that for a frame rate of 44100 Hz, I'm around 44 periods by
> >>second, which is less than a monitor refresh. And what if some user needs
> >>to set that up to 4096 frames/period or more ?
> > Wouldn't this mean that his system is very slow or at least needs such
> > slow settings to run stable?
> > Which in turn means, he is used to slow reactions of the system / the
> > gui... And even if the gui reacts at once to his changes, this would
> > confuse him, since the sound of his changes will be noticable later...
> I have a habit of deciding wether software is good or not according to its
> ability to run "fast" on slow systems, take for example the Gimp... I'm
> everyday amazed by the Gimp.
> And my first tests with a non-locking GUI greatly improve responsiveness on
> my Duron 700mhz system. Additionally, if 1024 frames/period is the default
> setting, that means it's the setting newbies will use, like musicians I
> know who consider the switch from Windows and who don't have a clue what
> jack is. They'll just get rpms or the like.
> With 1024 frames/period I expect a 64bits quad-cpu system to show GUI
> latency if I continue to lock (waiting for an ack from the RT thread) the
> way I do. In this case, even the newbie will laugh.

So I think we should distinguish between locked gui and a non-locked gui 
representing the real state as soon as the state is reached. Which might be a 
time after the user clicked the button.

We once encountered such things in the aRts-GUI: One of our tries we did set 
the volume from the mouseclick in the volumebar but did the repainting of the 
volumebar after the rest of aRts informed us about the volumechange. Which 
led to some slow responses of the fader...

Maybe with such big changes as deleting channels/track/whatsoever you should 
recreate/update the gui after the changes are made in the engine (so after 
they have an hearable effect). But to not confuse the user because nothing 
changes, perhaps you could gray-out the relevant parts in the time between 
starting the action and changing the gui.
Which would mean that you have a non-locked gui representing the real state of 
the engine...

Did I make may thoughts clear? Its before my first coffee/tea...

Arnold

-- 
There is a theory which states that if ever anyone discovers exactly what the 
Universe is for and why it is here, it will instantly disappear and be 
replaced by something even more bizarre and inexplicable.


There is another theory which states that this has already happened.

 -- Douglas Adams, The Restaurant at the End of the Universe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20050315/ea25883d/attachment.pgp>