LMMS consistently crashes after rendering 10 tracks with the "Export Tracks" file menu option. OS Windows 10, Version 1.2.0-rc4. Project file is 126 bars long, contains 5 empty beat/bassline tracks, 7 automation tracks, and 34 instrument tracks (11 ZASFX, 16 AFP, 9 3xOsc (2 of which are omitted from rendering)). Will grab and send additional system/project file/otherwise details if deemed necessary.
@Pyrif This is not a general issue. Try one of the demo projects
Best is to open the Demo-project-folder: //projects\cool_songs/Skiessi-Onion.mmpz and export that. Does that fail?
Imo this is a help-request, for errors on one specific project.
I do a lot of that in forum
http://lmms.io/forum/
If you open a ticket there, please post your:
A crash is a bug. @musikBear, stop directing bug reports to the forms. Discord (https://lmms.io/chat) #support and here (GitHub) are the EXACT place to report bugs.
Project file is 126 bars long, contains 5 empty beat/bassline tracks, 7 automation tracks, and 34 instrument tracks (11 ZASFX, 16 AFP, 9 3xOsc (2 of which are omitted from rendering)).
So it's one track that is problematic. You can just save it as a .mmp, zip it and submit here. Or you can first try and narrow the issue down a bit.
There's no singular problematic track. Tracks render from top to bottom, and after 10 tracks LMMS crashes. It doesn't matter which 10 tracks, if I disable the first 10 rendered, it renders the next 10 up and then breaks. If you would like to test the error, the file is attached.
Haunt Me.zip
It exports just fine here on SDL on what is soon to latest stable-1.2 06c40fc821a321a92924d97092806e7e7c412d38 .
What audio interface are you using?
I'm using SDL as well. Maybe the export options are at play here. During the usage of the Export Tracks option, I exported the tracks to OGG files, all options default save for setting the bit rate to 320kHz.
Maybe the export options are at play here
No, I am at play here... I tested this wrong and I do get some bugs with rendering tracks with the demo project Ashore. I'll try and see if there's a pattern to this. Here's a backtrace when crashing after one rendered tracks.
Program received signal SIGINT, Interrupt.
__lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007ffff7bc6664 in _L_lock_952 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007ffff7bc64c6 in __GI___pthread_mutex_lock (mutex=0xde28a0) at ../nptl/pthread_mutex_lock.c:114
#3 0x00007ffff62ab5fe in SDL_mutexP (mutex=<optimized out>) at ./src/thread/pthread/SDL_sysmutex.c:108
#4 0x0000000000581c7e in AudioSdl::stopProcessing (this=0xed8b70) at /home/zonkmachine/builds/lmms/lmms/src/core/audio/AudioSdl.cpp:110
#5 0x0000000000533703 in Mixer::stopProcessing (this=0xc34260) at /home/zonkmachine/builds/lmms/lmms/src/core/Mixer.cpp:251
#6 0x000000000053473d in Mixer::setAudioDevice (this=0xc34260, _dev=0x1ce9f10, _qs=..., _needs_fifo=false)
at /home/zonkmachine/builds/lmms/lmms/src/core/Mixer.cpp:608
#7 0x000000000054d93f in ProjectRenderer::startProcessing (this=0x7f7d850) at /home/zonkmachine/builds/lmms/lmms/src/core/ProjectRenderer.cpp:152
#8 0x0000000000551961 in RenderManager::renderNextTrack (this=0x24732a0) at /home/zonkmachine/builds/lmms/lmms/src/core/RenderManager.cpp:104
#9 0x000000000064a6b6 in RenderManager::qt_static_metacall (_o=0x24732a0, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0x7fff980041a0)
at /home/zonkmachine/builds/lmms/lmms/build/src/moc_RenderManager.cpp:57
#4 0x0000000000581c7e in AudioSdl::stopProcessing (this=0xed8b70) at
/home/zonkmachine/builds/lmms/lmms/src/core/audio/AudioSdl.cpp:110
void AudioSdl::stopProcessing()
{
if( SDL_GetAudioStatus() == SDL_AUDIO_PLAYING )
{
SDL_LockAudio(); <---------------- AudioSdl.cpp:110
m_stopped = true;
SDL_PauseAudio( 1 );
SDL_UnlockAudio();
}
}
@Pyrif It looks like rendering separate tracks from the command line might work. It does for me.
$ ./lmms --rendertracks ~/builds/lmms/lmms/data/projects/demos/Ashore.mmpz -o ~/outputdirectory
@PhysSong When I comment out SDL_LockAudio(); and SDL_UnlockAudio(); in AudioSdl::stopProcessing(), File -> Export tracks... works as expected.
@PhysSong When I comment out SDL_LockAudio(); and SDL_UnlockAudio(); in AudioSdl::stopProcessing(), File -> Export tracks... works as expected.
Also: reverting 020f1652bf08208458d53aa9d9fe038d1689b5d2 seem to fix this crash. I remember testing that PR thoroughly but I think I did the testing predominantly from the command line as the crashes where the same as under the gui and I could script it. _Edit: No, I was wrong. The crash is still there without 020f1652bf08208458d53aa9d9fe038d1689b5d2_
@PhysSong Can you look at this? I'm putting it on the 1.2.0 milestone.
So far this still works.
diff --git a/src/core/audio/AudioSdl.cpp b/src/core/audio/AudioSdl.cpp
index 2b810e9..07db1e7 100644
--- a/src/core/audio/AudioSdl.cpp
+++ b/src/core/audio/AudioSdl.cpp
@@ -107,10 +107,10 @@ void AudioSdl::stopProcessing()
{
if( SDL_GetAudioStatus() == SDL_AUDIO_PLAYING )
{
- SDL_LockAudio();
+ //SDL_LockAudio();
m_stopped = true;
SDL_PauseAudio( 1 );
- SDL_UnlockAudio();
+ //SDL_UnlockAudio();
}
}
Reproduced. This happens because LMMS restarts and stops the audio device between two track renderings. It can be fixed by changing the way renderer handles audio device changing.
Moving audio device (re-)storing from ProjectRenderer to RenderManager seems to fix this. LMMS restores audio device between track renderings, which turns out unnecessary.
It requires tiny refactoring in Mixer class, but it only affects rendering. I'll open a PR after doing some more tests. :smiley:
Most helpful comment
Reproduced. This happens because LMMS restarts and stops the audio device between two track renderings. It can be fixed by changing the way renderer handles audio device changing.