SSR crashes when new program connects to JACK system output

[unfa]

I've started SSR, started the capture and run LMMS.
SRR crashes the moment I run LMMS.

The same happens when I start playback in Audacity (it creates a new set of ports for every playback operation).

However after a moment it stopped, and Audacity play doesn't crash SSR.

I had an alsa_in process running and I thought it might cause this, but I re-run it and the problem didn't come back. Then it comes back again. SSR crashes even when recording is off (paused), and I play a sound from Audacity.

Here's console output:

unfa@unfa-K52Jc:~$ simplescreenrecorder 
==================== SSR started ====================
SimpleScreenRecorder 0.3.0
Compiled with GCC 4.8.2
Qt: header 4.8.6, lib 4.8.6
libavformat: header 54.20.4, lib 54.20.3
libavcodec: header 54.35.0, lib 54.35.0
libavutil: header 52.3.0, lib 52.3.0
libswscale: header 2.1.1, lib 2.1.1
[ALSAInput::GetSourceList] Generating source list ...
[ALSAInput::GetSourceList] Found plugin pulse = PulseAudio Sound Server.
[ALSAInput::GetSourceList] Found card hw:0 = Loopback.
[ALSAInput::GetSourceList] Found device hw:0,0 = Loopback PCM.
[ALSAInput::GetSourceList] Found device hw:0,1 = Loopback PCM.
[ALSAInput::GetSourceList] Found card hw:1 = HDA Intel MID.
[ALSAInput::GetSourceList] Found device hw:1,0 = CONEXANT Analog.
[ALSAInput::GetSourceList] Found card hw:2 = H2.
[ALSAInput::GetSourceList] Found device hw:2,0 = USB Audio.
[PulseAudioInput::GetSourceList] Generating source list ...
[PulseAudioConnect] Error: Could not connect! Reason: Connection refused
It is possible that your system doesn't use PulseAudio. Try using the ALSA backend instead.
[DetectCPUFeatures] CPU features: mmx sse sse2 sse3 ssse3 sse4_1 sse4_2
[PageRecord::StartPage] Starting page ...
[JACKInput::Init] Connecting port system:capture_1 to SimpleScreenRecorder:in_1.
[JACKInput::Init] Connecting port lmms:master out L1 to SimpleScreenRecorder:in_1.
[JACKInput::Init] Connecting port aqualung:out_L to SimpleScreenRecorder:in_1.
[JACKInput::Init] Connecting port system:capture_1 to SimpleScreenRecorder:in_1.
[JACKInput::Init] Connecting port alsa2jack:capture_1 to SimpleScreenRecorder:in_1.
[JACKInput::Init] Connecting port system:capture_2 to SimpleScreenRecorder:in_2.
[JACKInput::Init] Connecting port lmms:master out R1 to SimpleScreenRecorder:in_2.
[JACKInput::Init] Connecting port aqualung:out_R to SimpleScreenRecorder:in_2.
[JACKInput::Init] Connecting port system:capture_2 to SimpleScreenRecorder:in_2.
[JACKInput::Init] Connecting port alsa2jack:capture_2 to SimpleScreenRecorder:in_2.
[PageRecord::StartPage] Started page.
[JACKInput::InputThread] Input thread started.
[PageRecord::StartOutput] Starting output ...
[Muxer::Init] Using format matroska (Matroska).
[Muxer::AddStream] Using codec libx264 (libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10).
[libx264 @ 0x2563600] using SAR=1/1
[libx264 @ 0x2563600] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 0x2563600] profile High 4:4:4 Predictive, level 3.1, 4:2:0 8-bit                                                                                                                      
[libx264 @ 0x2563600] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=2 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=6 psy=0 mixed_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=4 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=1 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc=cqp mbtree=0 qp=0                                                       
[Muxer::AddStream] Using codec flac (FLAC (Free Lossless Audio Codec)).                                                                                                                          
[BaseEncoder::EncoderThread] Encoder thread started.                                                                                                                                             
[BaseEncoder::EncoderThread] Encoder thread started.                                                                                                                                             
[DetectCPUFeatures] CPU features: mmx sse sse2 sse3 ssse3 sse4_1 sse4_2                                                                                                                          
[Muxer::MuxerThread] Muxer thread started.                                                                                                                                                       
[DetectCPUFeatures] CPU features: mmx sse sse2 sse3 ssse3 sse4_1 sse4_2                                                                                                                          
[PageRecord::StartOutput] Started output.                                                                                                                                                        
[Synchronizer::SynchronizerThread] Synchronizer thread started.                                                                                                                                  
[PageRecord::StartInput] Starting input ...                                                                                                                                                      
[X11Input::Init] Using X11 shared memory.
[PageRecord::StartInput] Started input.
[X11Input::InputThread] Input thread started.
[FastResampler::Resample] Resample ratio is 1.0884 (was 0.0000).
[JACKInput::InputThread] Disconnecting port lmms:master out R1 from SimpleScreenRecorder:in_2.
[Synchronizer::ReadVideoFrame] Warning: Video buffer overflow, some frames will be lost. The audio input seems to be too slow.
cannot read result for request type 4 from server (Connection reset by peer)
unfa@unfa-K52Jc:~$

And here's at Audacity's playback:

[JACKInput::InputThread] Connecting port PortAudio-01:out_18 to SimpleScreenRecorder:in_1.
[Synchronizer::ReadVideoFrame] Warning: Video buffer overflow, some frames will be lost. The audio input seems to be too slow.
[JACKInput::InputThread] Connecting port PortAudio-01:out_19 to SimpleScreenRecorder:in_2.
cannot read result for request type 3 from server (Connection reset by peer)

[StripedMonkey]

[Synchronizer::ReadVideoFrame] Warning: Video buffer overflow, some frames will be lost. The audio input seems to be too slow.
cannot read result for request type 4 from server (Connection reset by peer)

[Synchronizer::ReadVideoFrame] Warning: Video buffer overflow, some frames will be lost. The audio input seems to be too slow.

That's your problem How to fix it I have no idea It is most likely a issue with LMMS or a hardware issue What kind of computer do you have? this also might be caused by extreme recording speeds that cause the slow down,

I'm no expert so don't ask me!
Help will come from others but this might not be seen for a little while I have no idea how often this is checked

[StripedMonkey]

Never mind about the computer question I can see that in the thing that you posted

[iamgreaser]

Sounds like LMMS is killing any running JACK server and starting its own. Perhaps you could try running LMMS first, and then seeing if it works?

Or maybe the "record speakers" thing is breaking - if so, you may want to manually hook stuff up. I suggest qjackctl for that.

[MaartenBaert]

I suspect it's a problem with "record speakers". Maybe some kind of race condition, possibly inside JACK since it appears to kill the server. If you run JACK from a terminal, do you see any error messages from the server?

[unfa]

I tried to see if JACK reports something, but I couldn't reproduce the crash yet.

[MaartenBaert]

Out of curiosity, are you using jack1 or jack2?

[unfa]

JACK1

I've reported a related issue in LMMS project. It's not exactly this, but I mention the trouble.
LMMS/lmms#1240

[MaartenBaert]

Have you tried to reproduce this with JACK2? If JACK2 is unaffected, then the bug is likely inside the JACK server or library.

[unfa]

I haven't. Sounds like I'd need my backup to recover after swiching from
JACK1 to JACK2.
26-10-2014 14:41, "MaartenBaert" [email protected] napisał(a):

Have you tried to reproduce this with JACK2? If JACK2 is unaffected, then
the bug is likely inside the JACK server or library.

—
Reply to this email directly or view it on GitHub
#250 (comment).

[iamgreaser]

My personal experience is JACK1 tends to be more stable than JACK2.

There's a chance that LMMS may require some JACK2 specifics, though.

[unfa]

I've now captured a 2+ hour material with SSR and jack_capture for audio.
I'll try to sync these together in Kdenlive.

Maybe the code of jack_capture could be helpful, as it managed greatly to capture all sound from start to end, even though LMMS have disconnected and reconnected to JACK numerous times, and even crashed a few times in the process. jack_capture still recorded all audio like it was connected to a hardware audio port. SSR also did great job, when I disabled audio capture at all.

Here's jack_capture: https://github.com/kmatheussen/jack_capture

[MaartenBaert]

If you record with SSR and you uncheck 'record system speakers', does it still crash? Or do you actually have to disable 'record audio' completely?

I suspect the crash happens in JACK itself. The code in SSR that handles this is relatively simple, I can't think of a way it could crash like this. I will take a look at jack_capture to see if they do anything significantly different.

Edit: interestingly, jack_capture does not go with the obvious solution (jack_set_port_connect_callback) and instead manually scans the connection graph after every single change. Maybe the author was aware of this bug and did this as a workaround?

[MaartenBaert]

I did some more testing, it seems I can make JACK lock up quite easily just by connecting/disconnecting too many clients per second. It looks like JACK can't handle more than a few dozen events per second, otherwise it starts printing various weird error messages and eventually just freezes. This happens even without SSR, but then the number of events needed to cause the problem is much higher.

SSR seems to have made the problem worse because I was holding a lock inside the 'connection change' callback and holding the same lock when calling JACK to change my own connections. Apparently JACK is designed to wait until applications have processed notifications, which can lead to a deadlock situation: SSR can't process notifications while changing connections, and JACK can't change connections when it is still trying to send notifications.

I still haven't figured out how this can lead to a crash. All I can tell is that the crash happens inside the JACK library and messes up the stack so much that I can't see a backtrace anymore.

Anyway, I changed the JACK input a bit so it doesn't hold the lock anymore while changing the connections. This seems to fix the problem - I can't make SSR or the JACK server lock up anymore unless I use an insane number of connections (~hunderds of new streams per second).

@unfa Could you please try to compile the latest SSR from source, and tell me whether this fixes the bug? I would like to test this change before I do a new release and update the PPA.

[the-drunk-coder]

I had the same problem in a different scenario (aplay through jack plugin popping up every few seconds).
Compiled latest SSR from source, now it seems to work fine !