I re-read the thread and have a few new comments. But first, can you refresh my mind on whether we discussed for you or me to resolve the conflicts and whether to use the squashed version?
Using '%' is notoriously slow (it's actually a DIV for the CPU), is there a
way the ring buffer is likely to be useful with power-of-2 values only?
[...]
As we're only speaking of a speculative optimization that I believe would
not make any difference at all here, I'm not particularily keen on changing
things, though. It works as it is, is tested, and I don't think it really
needs to be changed, or would make a measurable difference anyway.
I brought this up, because I've seen DIV causing heavy performance hits in
otherwise streamlined code several times when profiling and when tracing
slowdowns down to the instruction level. So yes, DIV does cause measurable
differences, which is why I default to avoiding it in supposedly fast code.
I'm not really convinced that this documentation is useful to the average
user, but it could help starting jackd if you normally don't use it.
https://github.com/swesterfeld/beast/blob/jack-driver/docs/howto-jack.md
While I don't know your average user, there certainly are people/tester/
contributors/etc that don't know the Linux audio stack and history as
intimately as you and can benefit from a description how to get things
to work when using your driver. Please take a look at the Beast manual
(e.g. from the ebeast menu or run make out/doc/beast-manual.html) and
make a suggestion where to fit this in. E.g. under '3.2. Howto Jack...' ?
Apart from audio, JACK can provide midi events to clients. Note that this
should be optional, and receiving midi events from ALSA should also be
supported.
Are you saying that when the jack driver is used, Beast should additionally
open MIDI devices via ALSA? Do other DAWs do this? At a future point, the
ALSA driver needs to auto-open all MIDI devices anyway so we can start
supporting MIDI auto-discovery. Is that still a good idea when IO should
be routed via Jack though?
Also, please point me at the docs for the exact MIDI event format in Jackd?
[using jack without ring buffer]
However this may pose stricter RT requirements onto BEAST.
I doubt that, the RT processing of our engine modules must run in bounded
time, which forbids e.g. malloc()/free() calls. Something jack isn't fully
following through in its own implementations (at least last time we discussed
the jack feasibility for Beast).
I don't think blocking jack for a full buffer calculation in Beast is a good
idea though, one reason to use jack at all is to plug multiple programs
together. What you suggest would severely reduce the CPU resources for other
programs during a PCM block's time frame.
Rather, Beast should be treated like some sort of external synth from jack,
i.e. one jack callback would do:
a) Send new MIDI (audio) data into Beast for the next engine block calculation.
b) Fetch the output block of the last engine block calculation to pass on to jack.
c) Wake up the engine so after the callback returns, the engine calculates exactly
one new block that can be fetched upon the next callback invocation.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.