musikinformatik / SuperDirt

Tidal Audio Engine
GNU General Public License v2.0
519 stars 75 forks source link

Big sur (in)compatibility #216

Open yaxu opened 3 years ago

yaxu commented 3 years ago

I've seen MacOS users increasingly report problems with the new 'big sur' os update. Tidal+SuperDirt work fine after a reboot but then timing drifts in one direction or the other, either causing 'late' messages or very long latencies. Some say this happens after a resume, but I'm guessing the problem is time since last reboot rather than a sleep-resume cycle in particular.

This is very likely caused by a general issue with supercollider + big sur: https://github.com/supercollider/supercollider/issues/5168

Just wondering if there is a workaround, how come supercollider uses a different time source to tidal - could that be fixed? Or with the new tidal<>supercollider API, could we do a quick+dirty hack, e.g. a 'resetClockDirtyHack' command that readjusts the latency via a simple ping-pong?

telephon commented 3 years ago

Yes, supercollider doen't support big sur yet, we should (have) warn(ed) tidal users.

One possible workaround, which may cause inaccuracies, but still better than nothing:

try to change in DirtEvent:

playSynths {
        var cutGroup;
        ~cut = ~cut.value;
        if(~cut != 0) {
            cutGroup = orbit.getCutGroup(~cut);
            ~hash ?? { ~hash = ~sound.identityHash }; // just to be safe
        };

        server.makeBundle(nil, { // <======================= 

            orbit.globalEffects.do { |x| x.set(currentEnvironment) };

            if(cutGroup.notNil) {
                server.sendMsg(\n_set, cutGroup, \gateSample, ~hash, \cutAll, if(~cut > 0) { 1 } { 0 });
            };

            this.prepareSynthGroup(cutGroup);
            modules.do(_.value(this));
            this.sendGateSynth; // this one needs to be last

        });

    }
yaxu commented 3 years ago

Had a positive report for this workaround, no perceptible differences so far. Thanks a lot @telephon !

yaxu commented 3 years ago

Ah I spoke too soon, they shared an audio file of the timing, it has a definite shuffle! https://slab.org/tmp/SC_201202_012946.mp3

yaxu commented 3 years ago

I guess another option is for tidal to do the timing and send messages to play 'asap'

yaxu commented 3 years ago

I tried sending as plain messages (no bundle), like this:

image

That works but causes late messages in sc. I can also hear jitter, which is probably quantified in the difference between late messages, e.g.:

late 0.059494577
late 0.064735330
late 0.070150778
late 0.051138094
late 0.057052164
late 0.061236595
late 0.066223818
late 0.048788407
late 0.053193565
late 0.058108672
yaxu commented 3 years ago

The Big Sur user reports that this is an improvement and they don't get late messages. It does sound better, I can sense a bit of a shuffle though:

https://slab.org/tmp/SC_201202_015301.mp3

This workaround is a case of editing BootTidal.hs, and changing the startTidal line to:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "127.0.0.1", oPort = 57120, oSchedule = Live}) (defaultConfig {cFrameTimespan = 1/20})

i.e. add the , oSchedule = Live bit

telephon commented 3 years ago

You could also try this (untested) branch I made:

https://github.com/musikinformatik/SuperDirt/tree/topic-send-immediate

Just set

~dirt.set(\latency, nil)

And hope for the best.

It will schedule the shuffle in the sclang scheduler (less efficient, but you can try.)

yaxu commented 3 years ago

There's a supercollider build that works apart from audio input https://github.com/supercollider/supercollider/issues/5168#issuecomment-751380391