PhysSong
commented
6 years ago Do you have a backtrace?
Open karmux opened 6 years ago
PhysSong
commented
6 years ago Do you have a backtrace?
karmux
commented
6 years ago Unfortunately it doesn't produce any traceback. gdb shows only this:
(gdb) run
Starting program: /home/karmux/lmms/build/lmms
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
*** WEAK-JACK: initializing
*** WEAK-JACK: OK. (0)
[New Thread 0x7fffeea71700 (LWP 10376)]
[New Thread 0x7fffe6d9a700 (LWP 10377)]
Notice: could not set realtime priority.
[New Thread 0x7fffdfdf5700 (LWP 10378)]
[New Thread 0x7fffde990700 (LWP 10379)]
[New Thread 0x7fffde18f700 (LWP 10380)]
[New Thread 0x7fffdd98e700 (LWP 10381)]
VST sync support disabled in your configuration
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
convolution: samplerate mismatch preset:48000 host:44100
[New Thread 0x7fffcc191700 (LWP 10383)]
[New Thread 0x7fff93fff700 (LWP 10384)]
[New Thread 0x7fff937fe700 (LWP 10385)]
[New Thread 0x7fff92ffd700 (LWP 10386)]
[New Thread 0x7fff927fc700 (LWP 10387)]
[Thread 0x7fff927fc700 (LWP 10387) exited]
[Thread 0x7fffde18f700 (LWP 10380) exited]
[Thread 0x7fffde990700 (LWP 10379) exited]
[Thread 0x7fffdd98e700 (LWP 10381) exited]
^C (it was stopping here and I had to Ctrl + C)
Thread 1 "lmms" received signal SIGINT, Interrupt.
0x00007ffff7f71f6d in __pthread_timedjoin_ex () from /usr/lib/libpthread.so.0
(gdb) Quit
(gdb) quit
A debugging session is active.
Inferior 1 [process 10372] will be killed.
Quit anyway? (y or n) y@karmux You can try thread apply all bt after pressing Ctrl + C. Also, do you use SDL1 or SDL2?
karmux
commented
6 years ago PhysSong
commented
6 years ago I can reproduce this with SDL2. The hang happens randomly, but LMMS almost always hang when closing after loading unfa-Spoken.mmpz.
It seems like SDL is waiting for its PulseAudio thread. I'm not sure if something is wrong on LMMS' side.
Unfortunately, I was unable to trigger the hang with a debug build of SDL2.
wolfram-omega
commented
5 years ago Same problem for me, every time I close LMMS. A backtrace with debug builds for sdl2 and pulseaudio:
Is there any additional information you need?
PhysSong
commented
5 years ago After some investigation, I found some interesting facts.
SDL_AUDIODRIVER=ALSA lmms, LMMS doesn't hang.However, I'm still not sure what can we do.
PhysSong
commented
5 years ago As @wolfram-omega's backtrace shows, it's related to the audio capture thread. If I comment out the call to Mixer::pushInputFrames() in AudioSdl::sdlInputAudioCallback(), LMMS doesn't hang anymore.
@Reflexe Do you have any ideas here? I'm asking you because you are working on the recording stuff.
Reflexe
commented
5 years ago Ok, The problem is that SDL waits for the PulseAudio thread to exit but it won't quit for some reason. The strange thing is, that nothing is stuck on lmms side. I suspect it is an upstream bug.
firewall1110
commented
3 years ago I found, that LMMS hung (on my Debian 10 system allways) on SDL destructor and with this "redaction"
AudioSdl::~AudioSdl()
{
stopProcessing();
#ifdef LMMS_HAVE_SDL2
//if (m_inputDevice != 0)
//SDL_CloseAudioDevice(m_inputDevice);;
if (m_outputDevice != 0)
SDL_CloseAudioDevice(m_outputDevice);
#else
SDL_CloseAudio();
delete[] m_convertedBuf;
#endif
//SDL_Quit();
delete[] m_outBuf;
}LMMS not hung more ...
firewall1110
commented
3 years ago Some more information: If LMMS opened it terminal (with ./lmms), than lmms freeze is seen and hanging threads will not killled after <Ctrl + Z> pressed (after this it seems , that LMMS stoped, but threads are not closed - pstree shows this). This threads are removed from system if terminal is closed. It seems that AppImage use "bash sand-boxing" - no problems with AppImage. If LMMS (compiled version) is opened by double clicking, there is illusion that no problem but pstree shows , that hanging threads are attached to file manager and slows down LogOut/ShutDown/Restart process.
firewall1110
commented
3 years ago (1) Experimenting with SDL2 I found that one lag in AudioSdl::sdlInputAudioCallback() will cause SDL2 hung on quit.
And now I found when and there it's happens:
Mixer.cpp ~305 line function requestChangeInModel(); waits when LMMS project is loading ~800 msec lag .
(2) I found , that function supportsCapture() is used only in SongEditor.cpp and AudioPortAudio.cpp not in Mixer.cpp @ Co ...
P.S.
Is it normal, than GUI thread not wait other threads to quit , and not trying to do something, if some of them not quit - hung ?
firewall1110
commented
3 years ago Minimalistic change in Mixer.cpp ~303 line:
void Mixer::pushInputFrames( sampleFrame * _ab, const f_cnt_t _frames )
{
bool needCapture = Engine::getSong()->isRecording(); //new
if (needCapture) { requestChangeInModel(); } // changed
f_cnt_t frames = m_inputBufferFrames[ m_inputBufferWrite ];
int size = m_inputBufferSize[ m_inputBufferWrite ];
sampleFrame * buf = m_inputBuffer[ m_inputBufferWrite ];
if( frames + _frames > size )
{
size = qMax( size * 2, frames + _frames );
sampleFrame * ab = new sampleFrame[ size ];
memcpy( ab, buf, frames * sizeof( sampleFrame ) );
delete [] buf;
m_inputBufferSize[ m_inputBufferWrite ] = size;
m_inputBuffer[ m_inputBufferWrite ] = ab;
buf = ab;
}
memcpy( &buf[ frames ], _ab, _frames * sizeof( sampleFrame ) );
m_inputBufferFrames[ m_inputBufferWrite ] += _frames;
if (needCapture) { doneChangeInModel(); } //changed
}And now there is no lag - and SDL quit without problems ...
Should I do PR?
qnebra
commented
3 years ago I think it is good idea. Any fix to lmms SDL perfomance will be good, as it is default backend in lmms.
firewall1110
commented
3 years ago Thank You for answer! I'll make PR in 1 - 3 days .
But "things are not so simple":
requestChangeInModel(); and doneChangeInModel(); must not be called from audio processing call-back , but it seems that recording (and capture monitoring) is not implemented so implementation can not be tested - LMMS project is not ready for this;
for performance reason capture call-back should not be on than is not needed (but needed only than recording/monitoring) - so needed some API to start/stop capture call-back;
anyway once LMMS was hung (now only once - not always) - so need some work-around in GUI (its lol , but now I know why my computer sometimes shut down so slow - if GUI closes , normal user not see any problem with LMMS, but experience computer performance degradation without any idea what's happens ... ).
My plan is: (A & B in parallel):
A
main (I know how implement now):
(1) do changes to call requestChangeInModel(); and doneChangeInModel();only than recording;
(2) do not start capture call-back on start but implement captureStart() and captureStop() functions as base class (it is AudioDevice) virtual functions and AudioSdl class implementation; and "connect" with partially implemented recording staff.
optional (I only have some ideas how to implement):
(3) find way how to insert capture monitoring - this makes possible testing other driver capture (makes possible to implement this - now only AudioSdl has capture and AudioPulseAudio has some draft for this.
B
make GUI to control such situations and try to work around - the basic is make message to user that LMMS manual "killing" or computer restart is needed. But I have no idea how to implement this right now, but after A will be merged to master - will be problems to test something that not needed right now.
Solution may be another PR with status "work in progress" after I find any minimal idea how to do this .
Key problem is - how to test?
firewall1110
commented
3 months ago I think should be closed: already fixed (SDL2 never hung on current master)
On master branch LMMS process keeps running after exit. I just open and close LMMS without loading any project. I'm using Manjaro Linux and SDL audio interface. This doesn't happen in stable-1.2 branch. Also this doesn't happen with PulseAudio in master branch. gdb doesn't show anything useful.