LinuxMusicians

Tim E. Real wrote:It's new since a month or two, it is enabled in Settings > Global Settings > Latency.
There's a whole thread and announcement here, a few posts down.

But I've a feeling this may be more related to Jack Transport... Since you're at 128 buf size.

I've completely removed everything MusE and reinstalled it.. I now have the latency tab but don't need it. All is fine now.
Thanks.

I just launched muse3 -j > logfile.txt, opening muse and just closing it.

saturnin51 wrote:I just launched muse3 -j > logfile.txt, opening muse and just closing it.

That was unfortunately a short one. Seems we log most startup to stderr and you need the & sign to pipe that also.

muse3 -j &> logfile.txt

I'll see if I can do some comparisons between MusE and qtractor myself.

The right file and a screenshot of audio setup.

Thanks, now the output seems correct.

Still a bit confusing what the problem is but the log indicates that your jack is running with 1024 buffersize: "JACK: buffersize changed 1024".

Assuming you are starting jack manually (which is the recommended way), how are you starting it, from the command line?
This is the command I generally use: pasuspender -- jackd -d alsa -d hw:0 -p 256 -r 44100
(the first part pasuspender disables pulseaudio if needed and proceeds to start jack with the selected parameters)

Why it seems to work better in qtractor etc I can't tell yet but if MusE is running with buffersize 1024 there will be a noticeable delay.

--
We are historically bad at giving clear info how MusE has been started. Both which driver, noaudio,jack or pulseaudio is running and what the settings for this interface are, buffersize and samplerate etc. It really should be visible in the application instead of needing to go through the console output.

The screenshot you sent is another good example where it gets confusing.
In some instances MusE can start jack by itself, then the selected parameters will be used. Most of the time though Jack is either started by the operating system or you started it manually before MusE, in which case the parameters are not used.

Hm, that screen is confusing, eh Robert?
It gives the impression that the samplerate and block size settings are for Jack.
But they are not. They are only for the dummy and RTAudio driver.

Tim E. Real wrote:Hm, that screen is confusing, eh Robert?
It gives the impression that the samplerate and block size settings are for Jack.
But they are not. They are only for the dummy and RTAudio driver.

Ah, ok, then I remember it wrong. I thought it was used when MusE starts jack by itself too. I can try to clarify/rework the dialog.

Also, I started on a diagnostics tab in the about box. There is now a new tab with information about the running instance. E.g. used audio driver, used timer, buffer size, samplerate etc. It's in master now.

It might be possible to use those settings.
I looked at using the Jack server API some time ago.
I can't remember if it's possible but there must be some way to start Jack with these settings
if it hasn't already been started. It'd be a shame if there wasn't...

Nope, appears not. Looking at QJackCtl source, we would have to do exactly what it does,
which is compose an actual command line to start Jack. But it's more than that, it has to check DBus etc etc...

Tim E. Real wrote:Nope, appears not. Looking at QJackCtl source, we would have to do exactly what it does,
which is compose an actual command line to start Jack. But it's more than that, it has to check DBus etc etc...

Okay. I'll consider that not a priority then..

I changed the dialog so the sample rate and size properties are grayed out when Jack is selected and added a tooltip that we cannot change this for jack.
While editing the tooltip I noticed that there was a blurb that smaller buffers improve midi timing.
For alsa midi that is not the case, right?
I know something similar was true for jack midi but is it still true? And if it is, should we really recommend using jack midi?

Correct about ALSA. It's the unsung hero in all of this.
Its timing depends on the chosen timer at startup. Not on some buffer size.

Whether to recommend Jack midi vs. ALSA ... Hm...

You know, after all that effort for Jack midi support, which DOES have its benefits,
ALSA is still a strong argument here. For example we support long chunked sysex because it does.
I see it in a more favourable light these days, as I mentioned some time ago that we could really
make it shine because we use it directly.

Perhaps for beginners we could recommend good ol' ALSA.

But of course that makes things awkward. We're a Jack app that supports Jack midi.
Users get the impression "Hey I'm good to go with only Jack then, and I can forget about ALSA..."
But of course it's not such a simple choice. To recommend ALSA seems odd though, but maybe necessary.

I use Muse with ALSA midi all the time:

(...)/muse-master/muse3/build/muse/muse3 -A