Quote:
Originally Posted by Jack Winter
OK, that's understandable. Makes me a bit sad though that my patch doesn't get tested or receives any feedback.. I had some more ideas that I wanted to follow up on, and now I'm not quite sure what to do. Maybe it's just easier if I fork it, and start working on my own project.
If I come up with something good, I can publish it to get public feedback. It probably means that our code bases will diverge and it will be difficult to merge the code again, something I really wanted to avoid! But I suppose that if I publish it on github, you could look at my git commits and pick up anything that is of interest to you.
Btw, your way of setting the realtime priority has the side effect of changing the priority of reaper's main thread, though I haven't noticed any adverse effect from this.
|
I tested them out when you sent me them and there is nothing wrong with them.
The problem is that plugins like mercuriall spark end up unbalancing the parent/child if real time priorities are just set (like I had them in earlier linvst versions) in the server threads (lin-vst-server) and also with your patches.
It seems that the parent (linvst.so) and child (lin-vst-server) need to have the same thread priorities set from the parent (linvst.so) and then the child inherits the parents thread priorities and it's all balanced.
If someone is on a dual core and they use mercuriall spark with my old server thread priorities or your priorities, then it becomes unusable and Reaper and other hosts lock up unfortunately.
From my latency tests on dual and quad systems using around 6 different sound hardware interfaces, the way I've got the priorities makes a large difference in reducing xruns and it seems to be ok in Ardour, Tracktion, Bitwig and Reaper.
If something comes along and gets the parent/child thread priority balance happening in a better way then I'm open to it.
Yes sure, you or anyone else can do their own version and try to improve on it.