We'll periodically copy the scheduling priorities from the host's audio
threads to the Wine plugin host's audio threads. The overhead of doing
this is about 1 microsecond on my system, so doing this every cycle
really adds up. But getting the Unix epoch time and comparing some
timestamps has a neglegible overhead, so this should give you the best
of both worlds.
Next we'll do the same thing for VST3 plugins.
As suggested by @jhernberg
To account for the differences in VST2 plugins and VST3 modules we had
to wrap most of our old functions from `src/plugin/utils.h` in a new
`PluginInfo` struct that gathers all of this information while taking
into account the differences between VST2 and VST3 plugins.
With this change things are also a lot more organized. We can just query
the plugin information we need rather than having to store things
separately or having to recalculate things. This also moved the
responsibility of all the weird `WINEPREFIX` behaviour to a single place
instead of having it spread around `utils.pp`, the initialisation
message, and `host-procoess.cpp`.
This is a pretty huge change that will be important for being able to
handle nested or mutually recursive `dispatch()` and `audioMaster()`
calls. This sadly all had to be done in a single commit, so here's a
summary:
- `src/common/sockets.h:Sockets` contains all sockets on both the plugin
and the Wine host side, and is used to both listen on and connect to
the sockets.
- Sockets and other temporary files respect `$XDG_RUNTIME_DIR` instead
of being dumped in `/tmp`.
- All sockets now have a unique endpoint in
`/run/user/<uid>/yabridge-<plugin_name>-<random_id>/`. This is
important for when we want to have multiple socket connections for
handling `dispatch()` and `audioMaster()`.
- Because of the above, we no longer clean up the socket endpoint files
after the connection gets established during initialization. Instead
we'll remove the socket base directory when shutting down.
This significantly reduces the latency with no real drawbacks from what
I've noticed. Wineserver is still run using the normal scheduling
policies because from my testing running that with realtime priority
that can actually increase latencies, although doing so will greatly
reduce the variance in processing time.
Robbert van der Helm