Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LMMS freezes at 100% on export #5664

Closed
ViperZer0 opened this issue Sep 2, 2020 · 24 comments
Closed

LMMS freezes at 100% on export #5664

ViperZer0 opened this issue Sep 2, 2020 · 24 comments
Labels

Comments

@ViperZer0
Copy link

Bug Summary

LMMS freezes at 100% on any exports that I try. I have tried to export three different projects, one which was new, and two older projects which I know had at one point successfully exported. Each one freezes at 100% and one closes entirely. Running LMMS from a terminal gives me the following error when the freeze/crash happens:
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'

The project that crashes gives an additional segfault.

Steps to reproduce

  • Create any project, the behavior does not seem to be affected at all by the contents of the project.

Expected behavior

Project should export successfully.

Actual behavior

LMMS freezes and sometimes segfaults at 100% exported, throwing the error
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'

Affected LMMS versions

Version 1.2.2
Arch Linux
JACK Audio

@ViperZer0 ViperZer0 added the bug label Sep 2, 2020
@trebmuh
Copy link
Contributor

trebmuh commented Sep 2, 2020

I've tried with the demo "CapDan-ReggaeTry".
I've got the same behavior where LMMS doesn't crash, but freezes.

Launched from a terminal, it says the same:
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'

LMMS 1.2.2, JACK, options:
export-options

Note that even if LMMS freezes, the WAV file seems to be correctly exported (ie: I can read it with VLC).

@Spekular
Copy link
Member

Spekular commented Sep 2, 2020

How long are you waiting to determine that LMMS is frozen? I know on my system, LMMS sometimes sits several seconds at 100% before the export completes.

You mention that you've succesfully exported projects before; what's changed since then? What was the latest configuration that worked?

@trebmuh
Copy link
Contributor

trebmuh commented Sep 2, 2020

@Spekular I've just run a test for 5 full minutes and it still is frozen.

Edit: 50 minutes and it sill is frozen. I had to Ctrl-C it.

@Daniele71
Copy link

It happens to me too. opensuse TW

@musikBear
Copy link

@ViperZer0 & @Daniele71
Are you both on Arch??
We need more information from you @Daniele71 !
I would like you both to try and change the backend to SDL, and retry to export, that way we can point the finger at JACK Audio
Change of backend:
https://lmms.io/wiki/index.php?title=LMMS_Settings#Audio_Settings
If you still freeze we can point at Arch

@Daniele71
Copy link

@ViperZer0 & @Daniele71
Are you both on Arch??
We need more information from you @Daniele71 !
I would like you both to try and change the backend to SDL, and retry to export, that way we can point the finger at JACK Audio
Change of backend:
https://lmms.io/wiki/index.php?title=LMMS_Settings#Audio_Settings
If you still freeze we can point at Arch

Opensuse Tumbleweed here. It works with SDL backend !

@trebmuh
Copy link
Contributor

trebmuh commented Sep 4, 2020

Same for me. Tested the export with the SDL backend, then tested with the ALSA backend, that works fine.

@musikBear
Copy link

Super! Thank you both @trebmuh & @Daniele71 for your feedback!
This issue is something related to JACK, or a version of JACK.
@trebmuh & @Daniele71
Afaik SDL output is not inferior to JACK, so you should use SDL for now :)

@trebmuh
Copy link
Contributor

trebmuh commented Sep 5, 2020

You're welcome. If that can help, I'm using a debian 1.9.14~dfsg-1 backport version of JACK2.

@firewall1110
Copy link
Contributor

The same problem is in master (I downloaded&compiled it at 15.09.2020).
Only after export and before freezing message is not:
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'
but (something about this):
PERFLOG | Project Render | 35.46user, 1.40system 17.39elapsed

I use Debian Buster : libjack-jack2-dev 1.9.12~dfsg-2

P.S.
Terminal output:
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'
is always after rendering - not only in Jack audio device, and after this only with Jack aufio device LMMS freezing. .

@DomClark
Copy link
Member

Can someone provide a backtrace of the hang? See https://github.com/LMMS/lmms/wiki/Debugging-LMMS.

@firewall1110
Copy link
Contributor

With stable release (1.2.2) compiled with QT4 i found, that Hung in

void waitUntilRead()
{
	m_writer_sem.acquire( m_size ); /* can not get this line done : but it is QT library call */
	m_writer_sem.release( m_size );
}

//fifo_buffer.h :: line 69

I made some fprintf(stderr, ...) to trace problem with session (last project DnB) exporting mp3 with default setting.
[----] With sdl device:
---- Mixer::stopProcessing():: 0
---- m_fifoWriter
---- m_fifoWriter->finish()
---- fifoWriter::run() -> write( NULL )
m_fifo->available() == True
--FB-- fifoBuffer::waitUntilRead()::m_size == 2 :: have = 2
--FB-- m_writer_sem.acquire( m_size )
--FB-- m_writer_sem.release( m_size )
---- fifoWriter::run() -> waitUntilRead()
---- m_fifoWriter->wait()
---- m_audioDev->stopProcessing()
---- Mixer::stopProcessing():: 1
---- m_fifoWriter == NULL
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'
--RM-- ~RenderManager()
--M-- restoreAudioDevice()
---- Mixer::stopProcessing():: 2
---- m_fifoWriter == NULL
--M-- stopProcessing()
--RM-- mixer()->restoreAudioDevice()
---- Mixer::stopProcessing():: 3
---- m_fifoWriter
---- m_fifoWriter->finish()
---- fifoWriter::run() -> write( NULL )
m_fifo->available() == True
--FB-- fifoBuffer::waitUntilRead()::m_size == 2 :: have = 1
--FB-- m_writer_sem.acquire( m_size )
--FB-- m_writer_sem.release( m_size )
---- fifoWriter::run() -> waitUntilRead()
---- m_fifoWriter->wait()
---- m_audioDev->stopProcessing()
--RM-- mixer()->changeQuality( m_oldQualitySettings )
---- Mixer::stopProcessing():: 4
---- m_fifoWriter
---- m_fifoWriter->finish()
---- fifoWriter::run() -> write( NULL )
m_fifo->available() == True
--FB-- fifoBuffer::waitUntilRead()::m_size == 2 :: have = 2
--FB-- m_writer_sem.acquire( m_size )
--FB-- m_writer_sem.release( m_size )
---- fifoWriter::run() -> waitUntilRead()
---- m_fifoWriter->wait()
---- m_audioDev->stopProcessing()

[----] With jackd device:
---- Mixer::stopProcessing():: 0
---- m_fifoWriter
---- m_fifoWriter->finish()
---- fifoWriter::run() -> write( NULL )
m_fifo->available() == False
--FB-- fifoBuffer::waitUntilRead()::m_size == 2 :: have = 0
--FB-- m_writer_sem.acquire( m_size )
--FB-- m_writer_sem.release( m_size )
---- fifoWriter::run() -> waitUntilRead()
---- m_fifoWriter->wait()
---- m_audioDev->stopProcessing()
---- Mixer::stopProcessing():: 1
---- m_fifoWriter == NULL
QMetaMethod::invoke: Unable to handle unregistered datatype 'MidiTime'
--RM-- ~RenderManager()
--M-- restoreAudioDevice()
---- Mixer::stopProcessing():: 2
---- m_fifoWriter == NULL
--M-- stopProcessing()
--RM-- mixer()->restoreAudioDevice()
---- Mixer::stopProcessing():: 3
---- m_fifoWriter
---- m_fifoWriter->finish()
---- fifoWriter::run() -> write( NULL )
m_fifo->available() == True
--FB-- fifoBuffer::waitUntilRead()::m_size == 2 :: have = 1

[Actual files are: fifo_buffer.h , Mixer.cpp , RenderManager.cpp ]

@firewall1110
Copy link
Contributor

I found more bugs in rendering:

the same is in portaudio device:
[using direct sound card name:]
lmms_portaudio.txt
[using oss "virtual" device:]
lmms_portaudio_oss.txt

But with soundio device there is SegFault on export start (exception with compiled version, but infinite loop with AppImage 1.2.2):
lmms_soundio_dummy.txt
lmms_soundio_pulse.txt

P.S.
All bugs are both in stable and master versions (in lmms-1.2.2-linux-x86_64.AppImage I can not set direct sound card with portaudio - no sound).

@firewall1110
Copy link
Contributor

I clear this:
lmms_jackd_freeze_gdb.txt

But I think it is not more actual ...

@firewall1110
Copy link
Contributor

firewall1110 commented Sep 19, 2020

This bug is related to #2638

[Thank You, PhysSong !]

This can be formulated:

Some (playable) devices have problems in Mixer::stopProcessing():
soundio : Segmentation Fault

jackd and (sometimes) portaudio :
no sound after Mixer::stopProcessing() , Mixer::startProcessing() ;
and hung in next Mixer::stopProcessing() .

P.S.

In my experiment I replaced
void Mixer::restoreAudioDevice()
and
void Mixer::changeQuality( const struct qualitySettings & _qs )

with

void Mixer::restoreAudioDeviceWithQuality( const struct qualitySettings & _qs )

In original code
Mixer::stopProcessing() //<- befor rendering (export)
and
Mixer::startProcessing() ; Mixer::stopProcessing() ; Mixer::startProcessing() ;
after rendering (export)

@firewall1110
Copy link
Contributor

Sorry for my mistake ...

soundio crash with segmentation Fault in Mixer::startProcessing() ;

but problem is in Mixer::stopProcessing()

Line in AudioSoundIo.cpp:
void AudioSoundIo::stopProcessing()
{
m_stopped = true;
if (m_outstream)
{
soundio_outstream_destroy(m_outstream);
// line 228 :: after this we can not simply soundio_outstream_start(m_outstream)) - Segmantation Fault!
m_outstream = NULL; // Segmantation Fault in every conditions
}

if (m_outBuf)
{
	delete[] m_outBuf;
	m_outBuf = NULL;
}

}

@firewall1110
Copy link
Contributor

It seems that this bug can be fixed by adding only one line:

void AudioJack::startProcessing()
{
	if( m_active || m_client == NULL )
	{
		m_stopped = false; // Only this should be added
		return;
	}
...
}

Patch file:

lmms_5664.diff.zip

But I have one pending PR ...

@qnebra
Copy link

qnebra commented Sep 20, 2020

It doesn't matter how many pull requests you had open. Made new PR if it fixes issue.

@firewall1110
Copy link
Contributor

It seems that I instead have added change to my pending PR ...
Is it problem?

@PhysSong
Copy link
Member

Not that much at this moment. We can split them before merging if we should.

@firewall1110
Copy link
Contributor

I think it would be better to work with them both (not splitting): second change is too small - only 1 line.

@firewall1110
Copy link
Contributor

PR patch against stable LMMS 1.2.2 :
lmms_1_2_2_stable.patch.gz

@DomClark
Copy link
Member

Fixed in #5681.

@trebmuh
Copy link
Contributor

trebmuh commented Oct 30, 2020

Awesome.
Thank you all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants