No. Some of them have come from various DJ pools.
It’s worth noting this only happens when I’m streaming. In that case I’m using JACK through to OBS. The rest of the time I’m relying on ALSA as I don’t run JACK by default.
Have you tried using JACK when not streaming?
I have not. And I think I found the problem in the JACK logs.
So, when I’m running normally with ALSA I have it set to 48k / 256 samples. JACK is running 48k / 512 samples. I assumed this was enough to avoid xruns, but clearly that’s not the case. I have three issues tonight between 10 and 11 PM. When the application stopped playing, but was still responsive input. A failure to launch after closing it down and restarting it. Then another stop while responsive to input.
22:36:21.273 XRUN callback (2). 22:36:21.273 JACK connection graph change. subgraph starting at Mixxx timed out (subgraph_wait_fd=14, status = 0, state = Running, pollret = 0 revents = 0x0) **** alsa_pcm: xrun of at least 0.560 msecs internal poll failure reading response from client Mixxx to a xrun event
22:37:09.140 XRUN callback (3). subgraph starting at Mixxx-01 timed out (subgraph_wait_fd=17, status = 0, state = Finished, pollret = 0 revents = 0x0) pp: cannot clean up byte from graph wait fd - no data present **** alsa_pcm: xrun of at least 0.257 msecs subgraph starting at Mixxx lost client timeout waiting for client Mixxx to handle a xrun event **** alsa_pcm: xrun of at least 662.468 msecs
subgraph starting at Mixxx-01 timed out (subgraph_wait_fd=14, status = 0, state = Running, pollret = 0 revents = 0x0) 22:45:53.220 XRUN callback (5). 22:45:53.220 JACK connection graph change. **** alsa_pcm: xrun of at least 0.406 msecs internal poll failure reading response from client Mixxx-01 to a xrun event
My guess here is that the xrun is causing a drop in the connection and Mixxx then stops playback as it no longer has an appropriate output. It would explain why reloading Mixxx fixes the problem as it reconnects to JACK.
Woof. I guess 1024 and 40 ms latency.
Are you broadcasting audio from Mixxx or from OBS?
Broadcasting from OBS to Twitch.
Audio path is Mixxx > JACK > OBS > stream
I’m not too familiar with the JACK protocol. Perhaps there is something that JACK is expecting that Mixxx does when it is connected to another software using JACK and there is an xrun which doesn’t matter if Mixxx is connected directly to the audio interface via JACK. Can you try using JACK with Mixxx outputting to the audio interface without OBS? Maybe lower the buffersize and use keylock with extreme ranges to increase the chance of xruns.
256 or lower and I get xruns while Mixxx is loading.
subgraph starting at Mixxx timed out (subgraph_wait_fd=9, status = 0, state = Running, pollret = 0 revents = 0x0) **** alsa_pcm: xrun of at least 0.776 msecs internal poll failure reading response from client Mixxx to a xrun event
It loads, but then it won’t play or load any tracks. If I try to load a track it will start, but the waveforms never load up and I can’t play anything.
At 512 I can’t get it to cause an xrun even at 90% tempo slider with keylock, all four tracks going, fx on each, recording locally in Mixxx, and recording video in OBS (unconnected via JACK for audio).
Learned a tiny piece of information last night when this happened again last night while streaming.
I’ve started using Catia because I like the patchbay style routing. When Mixxx soft locked all the routing in Catia disappeared. It only does this if JACK is shut off or not available. As soon as Mixxx was closed all the routing came back. I was able to just restart Mixxx and pick back up again. It feels like something is causing JACK to become unavailable and then Mixxx is preventing it from starting back up again.