jack-midi support

[lyrra]

• I signed the CLA

Purpose

For linux users, the ability to at runtime switch between alsa and jack audio+midi driver.

Changes

• Make both jack and alsa(linuxdriver) more similar to osx-driver
• Make jack and alsa drivers "subdrivers" of linuxdriver (AudioDriverState).

class design changes

Before:

AudioModule
│
├── LinuxAudioDriver
│   │
│   Alsa
│   └──> device: "default"
│
├── OSXAudioDriver
│   ...
│
└── WasapiAudioDriver
    ...

MidiModule
│
├── LinuxAudioDriver
│   │
│   ├────> AlsaMidiOutPort
│   └────> AlsaMidiInPort
│   
:

After:

AudioModule
│
|         MidiModule
│             |
├── AudioMidiManager (was LinuxAudioDriver)
│        |      │
│        |      ├─── JackDriverState
│        |      │    │
│        |      │    (jack-code)
│        |      │    └──> jack client open
│        |      └──> AlsaDriverState
│        |                      │
│        |              (alsa-code)
│        |                      └──> device: "default"
│        │
│        + LinuxMidiOutPort
│        │
│        ├────> JackMidiOutPort
│        ├────> AlsaMidiOutPort
│        + LinuxMidiInPort
|          :
│
├── OSXAudioDriver
│   ...
│
└── WasapiAudioDriver
    ...

MidiModule
│
├── AudioMidiManager (was LinuxAudioDriver)
│   │
│   + LinuxMidiOutPort
│   │
│   ├────> JackMidiOutPort
│   ├────> AlsaMidiOutPort
│   + LinuxMidiInPort
:

Audio Tests

• start with jack, play and hear audio OK
• start with alsa, play and hear audio OK
• start with jack, switch to alsa, then play OK
• start with alsa, switch to jack, then play OK
• switch from jack to alsa during play OK
• switch from alsa to jack during play OK

Midi tests

• start fluidsynth in verbose mode, musescore and qjackctl (to midi-connect them), verify midi-events are logged by fluidsynth.

Optional cleanups / redesign

Remove LinuxAudioDriver and keep only AlsaAudioDriver and JackAudioDriver as two independent implementations. To switch between them, you need to add another class, something like IAudioDriverProvider. This is what you need to add to IoC (and remove the drivers from IoC). Access the driver through this class, like:

class IAudioDriverProvider ...
{
...

        std::shared_ptr<IAudioDriver> driver() const;
  
        void swithDriver(const std::string& name); 
        async::Chanel<std::string /*name*/> dirverChanged() const;
}


class SomeClass
    Inject<IAudioDriverProvider > audioDriverProvider;


...

     audioDriverProvider()->driver();

This greatly simplifies everything, each class becomes simple and does one thing.
Moreover, such a system is easily scalable; we can easily add other drivers, cross-platform or platform-specific.

Not in scope for this PR

• MIDI-channel-per-instrument

Known cleanups & fixes before merge

• send foreign commits upstream:
  Misc. needed for jack #22373
• cleanup: avoid global in app
• If possible do mutual dependency Injection between module Audio and Midi.
  Testing confirmed, can't inject modules.
  Injection is used, but not at modul level.
• de-pollute any interfaces that got sprinkled with data members
• ensure no public data members begins with m_ (those should be private)
• remove sample-rate dropdown OR make it work,
  No 'requires restart' added
• automatic connection to audio ports upon start
  Not in scope, brings in too much arbitrary heuristics code from Mu3.
• Possible to switch between jack/alsa driver (currently it crashes)
• Possible to switch bufferSize in jack without crash (possible in alsa)

[cfirwin3]

This is the only branch that seems to work for me in Ubuntu 24.04. Yikes! The master release doesn't properly connect to audio or play back in the latest OS (which is the LTS release). Jack capability may be necessary and most dependable going forward with Pipewre being the default sound server.

EDIT: Ubuntu (Studio) 24.04 has Pipewire set by default to 48000. That's why this branch works while the trunk does not. One can (if they figure it out) switch Pipewire to 44100 to use M4 master trunk.

I think that a sample rate selection is essential for M4 and if this branch can resolve that issue as well, that would be great.

[lyrra]

I think that a sample rate selection is essential for M4 and if this branch can resolve that issue as well, that would be great.

This branch has a samplerate selection (dropdown), it should work. The only issue is that it requires a restart of Mu, so perhaps a warning message of that would be nice too (but not in scope for this PR as I dont know how).

Also, there should be a checkbox to turn off jack transport, because it is a bit intrusive if not being used. That shouldn't be too much work because there exist prior work we can copy.

[cfirwin3]

I think that a sample rate selection is essential for M4 and if this branch can resolve that issue as well, that would be great.

This branch has a samplerate selection (dropdown), it should work. The only issue is that it requires a restart of Mu, so perhaps a warning message of that would be nice too (but not in scope for this PR as I dont know how).

Also, there should be a checkbox to turn off jack transport, because it is a bit intrusive if not being used. That shouldn't be too much work because there exist prior work we can copy.

I see the drop down in the Linux build, but it only has the default 48000 in the closed field and the drop down box is empty. I remember a build quite a while ago that listed sample rates, but the current one doesn't seem to have options.

[cfirwin3]

So it looks like you can run multiple M4 sessions in sync and mix down to DAW with this branch:
https://youtu.be/0Xdy4zMXPZ8?si=iLXVmH8moYENEmbp

If anyone was wondering.