"Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx> writes: > On Fri, Oct 16, 2009 at 04:25:21PM +0200, hollunder@xxxxxx wrote: > | Hi, > | I'm a Linux audio user and following the rt kernel development closely > | (only as a user). > | I've experienced something that might be relevant for all of us. > | > | When loading the plug-in 'lv2fil' in one of our most relevant > | Linux audio applications, ardour, and opening the ui, fork() was used. > | This usually blocks the rt thread long enough to wreak havoc to the > | underlying rt audio server jack. > | > | What's relevant here is the ill effect of fork() and that tests > | showed that vfork() works a lot better. > | One ticket associated with this is: > | http://nedko.arnaudov.name/soft/lv2fil/trac/ticket/9 > | > | Ardour also uses some gtk function (to open a page in the > | default webbrowser) that uses fork() and causes the same problem. > | > | Again, it seems the problem stems from the fork() implementation and is > | present at least in 2.6.21.x through 2.6.31.x(-rt). > | I'm quite sure this doesn't only affect us audio people. > | > | I hope this information is of help and someone will look into it. > > Do you know how people benchmarked fork, vfork and clone? Is it easier than > reproducing the issue you observed? I did some benchmarks, IIRC, vfork was slower than fork; clone and clone2 were giving xruns and were not faster. > Another question that comes to mind is: was Ardour running with a realtime > priority too? Higher or lower prio than jack's? Ardour process has realtime thread(s) started by libjack. If someone is interested, lv2fil code has disabled code for measuring fork-and-like execution time. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Attachment:
pgpFAeEPXPVg7.pgp
Description: PGP signature
