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? Another question that comes to mind is: was Ardour running with a realtime priority too? Higher or lower prio than jack's? Regards, Luis -- [ Luis Claudio R. Goncalves Bass - Gospel - RT ] [ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ] -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
