On 12/24/2017 03:14 PM, Robert Jonsson wrote:
2017-12-24 4:38 GMT+01:00 Tim <[email protected] <mailto:[email protected]>>:
<..>
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.
Alright cool.
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 ;-)
There is one more hack we can apply: Checking if the jackd process, it's
not bulletproof but 99% chance you want to use jack if the process exists.
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.
We could check for pulse process too before trying to connect with
pulse, I guess. Not sure if this is as reliable..
I guess we'll sleep on that one for a bit.
--
I added support for changing sample rate when loading songs now too.
Works fine for pulse anyway :)
Ah yes, I was thinking the very same thing, that we could use a
friendly dialog each time MusE starts, very similar to Ardour.
Users could choose which exact driver and sample rate to try
before MusE tries to start up the drivers and engines.
I may have misstated the driver choice problem before.
I think now, that possibly the default driver should not be
rtAudio Pulse but our Jack driver.
Thus it will try Jack first, and if that fails it will fall back to
rtAudio, and if that fails fallback to dummy.
Thus it at least still tries to honour the user's choice, but the
default will be our Jack driver.
I think I can make that work... possibly. Lemme test and report back.
And if we include all this stuff in a startup dialog, it'll sure help.
I saw you managed to catch the ellusive silent part bug, awesome! A long
time running bug, that one.
Dunno what you think but what I see this far is very stable so I'm
anxious for doing the 3.0 release later this week. if you don't mind?
The bug that I talked about a while ago with transposed synths either
is gone or only happens sometimes as I could not reproduce it on my
laptop. I'll try on the other computer too.
In either case, I don't think it's a release stopping bug, there is
always a 3.0.1.
Yes, let this be not as much a /closing/ of 2.x as a /new/ beginning
with some new stuff in there.
And... in the very near future my resampling/stretching/shifting
branch can be merged for MusE 3.0.1
After that... latency correction. Then that makes it /all/ worth it.
MusE will be truly grown up and worthy at that point, I think.
Regards,
Robert
------------------------------------------------------------------------------
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
