On 12/23/2017 03:03 PM, Robert Jonsson wrote:
Hi Tim,
2017-12-23 20:38 GMT+01:00 Tim <[email protected] <mailto:[email protected]>>:
Hi Robert, just to let you know I'm trying to fix some
problems in there, don't want to step on your toes
but I need to move on, I've got a couple of bugs
in my mega-commit to fix.
Maybe you're already working on it?
Ah, I didn't test too much yet but wasn't aware of any immediate problems.
No worries about my toes I'm aware of my limits and there are bound to
be bugs and omissions. :)
The way I see it, no problems if you want to get in there and fix it up
but I know you have bigger fish to fry so I can definitely try to get it
sorted myself. If you start with the -.j parameter it should behave
mostly the same as before.
Yeah couple of my bugs to be aware of: I made song dirty /too/ sensitive
now and things like 'transport stop' make it dirty. I Must revert a
small piece of code, but unfortunately it means that monitor, mute,
solo and record won't dirty the song now unless I find a better way...
Also I need to finish a wee thing: When a track is soloed, muted,
or turned off it needs to affect the /sustain/ controller of itself
and/or other midi tracks otherwise some notes may hang - even if the
notes have been turned off, as you might imagine.
Codewise the rtaudio backend isn't that big but it's a pretty big change
for MusE and that I decided to switch it over to starting pulse instead
of jack.
When Jack is running MusE should never try to start rtAudio,
especially with the Pulse driver, it hangs because you cannot
start both Jack and Pulse.
Sorry, I think that's true only if the system was not set up properly,
see below...
Ah, yes I see what you mean now. I did the switchover last night in a
speed coding session and I didn't consider this. Also I should have
asked you, before doing this change, what you thought, though I think
it's the right thing to do in the long run.
I'll try to take care of that now, it's tricky since we
cannot easily ask if a Jack server is running.
Doing so essentially involves attempting to start the server
anyway. Therefore I believe the correct solution is to, in
the absence of any overrides such as -a or -t, /always/ try
to start Jack first (since per above, we must try anyway),
then rtAudio, then our dummy driver.
I think there may be an easier way to ask if Jack server is running.
Just ask it to start /without/ the autostart flag. It'll tell us
in the return value and status.
Yeah I see it now, should definitely try to connect to jack (without
autostart set) before doing what the configuration says.
Nah, I decided against it, see below...
Also, my last sample rate was 88200 using our dummy driver.
(Don't ask, it's for testing my resample branch.)
Thus when I tried to start MusE with these commits, rtAudio
tried to start Pulse and said "unsupported sample rate".
Now, after that it hung, but Jack was already running so
I think that's why, but I'm curious what rtAudio and Pulse
will do when they /do/ start properly (without Jack running.)
I wonder if they will fall back to another sample rate.
Or just fail and /we/ need to fall back to another driver
or choose another sample rate /ourselves/ and try again
before the program can move on...
RtAudio will setup a driver with the samplerate set in the configuration
so it will very likely be wrong.
Though, with RtAudio we should be able to quite easily restart the audio
driver upon song startup and set the samplerate to whatever the song
wants. I can take a look later.
I think I got it much better now, see below.
Regards,
Robert
Fixed compile error on unknown 'DummyAudio'.
Automatically chooses nearest lower sample rate if requested
rate is unsupported. Prevents freeze in MusE msg system because
driver did not start.
If driver cannot be started, it warns with a message box but MusE
still runs so that user can change the driver.
Robert you're right, I decided not to force Jack or anything like that.
The reason is that I know that at least on (U)buntu things are setup
nicely and Pulse and Jack usually /do/ work together.
So it obeys what the user has chosen in the config but gracefully
keeps running and allows them to change it if driver didn't start.
But for us slobs running say SUSE, Pulse and Jack don't work together
out of the box, so rtAudio /will/ freeze when starting. Oh well.
Apart from manually setting up the system, the only way out of that
situation is to have a watchdog thread and when the rtAudio gets
stuck waiting for Pulse, we do something else.
Or, we could ask the rtAudio team to find an internal workaround.
Or, we could, as Mr. Davis has pointed out, ask that these distros
set up Pulse and Jack properly out of the box ;-)
So, if the system is not set up properly, selecting Pulse backend
while Jack is already running may cause MusE to freeze. Likewise,
selecting Jack backend may cause Pulse to pause.
Cheers!
Tim.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
