On August 20, 2013 09:58:47 PM Robert Jonsson wrote:
> Hi Flo,
> 2013/8/20 Florian Jung <flo@...>:
> > Hi,
> > for my current work on MusE, i stumbled upon the various threads MusE
> > uses:
> > - GUI thread
> > - OSC thread
> > - jack thread
> > - ALSA thread
> > is that correct?
Sounds about right, plus audioPrefetch in current source.
Use a debugger to show all threads.
> Browsing the code I found audioPrefetch, but maybe you removed that one
> > What is the ALSA thread for? Is it still of imporant use, or is it only
> > legacy?
> Are you talking about the sequencer thread?
> If I remember (and understand) correctly it's a polling thread to
> transfer midi data from/too the devices.
> It's running at a fast rate (driven by a tick timer) to minimize
> jitter in the recording and playback.
Yes we talked about this, don't remove it, try to make it configurable
if user doesn't want ALSA.
I've been wanting to try but lack of time, other fixes are on my plate.
But remember, DSSI wants ALSA. The simple 'DSSI-ALSA' compatibility
package available in most distros and BSD, should suffice in that case.
> > Which threads have read and which have write access to the Song, Track,
> > Part and EventList data structures?
> Can't really help there.. probably they are used in too many places.
Whew, tough one.
Note this is not an exhaustive synopsis of usage, there are exceptions
and intricacies involved. Best to follow the actual loops involved, which
I know is very complex for audio thread but not so hard for the others:
GUI has write access but it will either use msgXXX for a synced access for
fairly simple operations, or msgIdle to completely put the audio engine in
idle mode with no processing (very minimal message processing and stuff)
over many cycles for lengthy operations (causes muted audio 'glitch' but
at least it will not cause xruns). GUI will usually read directly.
msgIdle usage example: When recording is stopped - there's a small mute glitch
because of the potentially long operations after recording. A user complained
about that once but what can we do, we have to find a way to spread long
GUI operations over several cycles without interrupting audio.
Our OSC thread callback doesn't directly access anything.
We delegate where the received OSC messages should go (currently only
DSSI rack plugin vs. synth) and then put them into a respective ring buffer,
then the audio thread processes the ring buffers upon each cycle
(either during rack plugin processing or synth processing).
Jack thread, well that one's obvious. It's the audio thread cyclic callback
ie what drives our whole audio (and some midi).
This thread writes the mentioned items via message processing msgXXX,
but during the audio processing code it tends to use ring buffers to receive
communication, events, and values, from other threads.
As I mentioned the other day, I need to expand on ring buffer usage.
Note that a few msgXXX messages are actually ALSA thread messages
meant to be processed by the ALSA thread not by audio thread.
Making ALSA 'configurable' or removing it, involves among other things,
finding suitable ways to process those few particular messages in the audio
thread instead of the ALSA thread.
Note that when Jack is not running, we use a dummy audio thread instead
which mimics some of the things Jack can do (like transport functions,
and slow-sync support I think).
ALSA thread. As Robert says, it's for polling the ALSA timer.
ALSA is important because it allows a large Jack period, yet allows for
fast, fine resolution processing of ALSA events depending on the timer.
ALSA thread generally does not read or write very much stuff you mentioned,
except perhaps those few specific msgXXX messages mentioned above.
Note that the timer section needs to be rewritten and we need to *dump* that
external RTC stuff and go with library or ALSA -based high-speed timer.
Take a look at QTractor's timer setup dialog in user settings.
See that one of the choices of QTractor's timers in the available list, is a
very high speed timer (can't remember either ALSA based - or 'newer' RTC).
Observe what this timer rate says in the list - it's billions per second.
That is what *we* need.
Because stock kernels set the RTC rate at a pitiful 250Hz.
Get rid of that very old *obsolete* RTC poking user-instructions stuff,
it's too hard for user to set up, although it does work.
Then we're laughing.
We could also use these high speed timers for other things.
FYI There is at least one other thread (besides audio prefetch).
There is a thread for loading SoundFonts into our FluidSynth
Oddly enough, it is the *only* place in MusE where mutexes are used !
> > Please reply quickly, a correct understanding of this is critical for my
> > further work.
> Atleast I was a bit quick :)
> > Greetings,
> > flo