Menu
▾
▴
#1428 Crash on squash or stretch audio segment
Suddenly rosegarden will not stretch or squash anything without crashing. oddly it started in a virtual machine running the package and OS from ubuntu 10.04. Tried running it in rosegarden 14.02 with the same result: import a file, try to stretch or squash it, crash. Here is the minidump from the instructions:
(gdb) where
#0 0x00007fc0cd45b407 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fc0cd45c7e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007fc0cff2bc22 in qt_message_output(QtMsgType, char const*) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3 0x00007fc0cff2bf89 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4 0x00007fc0cff2c1d4 in qWarning(char const*, ...) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5 0x00007fc0d0047196 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6 0x00007fc0d004becd in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7 0x00007fc0d1c0e14e in ?? ()
#8 0x00007fc0d1c3b39d in ?? ()
#9 0x00007fc0d004aa7a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#10 0x00007fc0d0aee912 in QAction::triggered(bool) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x00007fc0d0af02e3 in QAction::activate(QAction::ActionEvent) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007fc0d0f22569 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x00007fc0d0f26c09 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x00007fc0d0b446c8 in QWidget::event(QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
---Type <return> to continue, or q <return> to quit---
#15 0x00007fc0d0f2aa2b in QMenu::event(QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x00007fc0d0af4c0c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x00007fc0d0afb4ae in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#18 0x00007fc0d1c0159b in ?? ()
#19 0x00007fc0d003686d in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#20 0x00007fc0d0afab6f in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#21 0x00007fc0d0b6d9fd in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x00007fc0d0b6c022 in QApplication::x11ProcessEvent(_XEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x00007fc0d0b94212 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#24 0x00007fc0ccd11e04 in g_main_context_dispatch ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007fc0ccd12048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007fc0ccd120ec in g_main_context_iteration ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007fc0d0063ffd in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
---Type <return> to continue, or q <return> to quit---
#28 0x00007fc0d0b942c6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#29 0x00007fc0d00354f1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#30 0x00007fc0d0035805 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#31 0x00007fc0d003af67 in QCoreApplication::exec() ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#32 0x00007fc0d18e2b6a in ?? ()
#33 0x00007fc0cd447b45 in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#34 0x00007fc0d18ee1f4 in ?? ()
(gdb)
What you have there is a Qt warning crash. I can't repeat the crash here, so I can't do much to investigate the underlying problem. Qt warning crashes happen as a result of hundreds of conditions that are frequently trivial, and usually have little or no impact on end use.
If you rebuild as a production build, without debugging, that's supposed to make Qt warning crashes go away. You can probably rebuild and continue with your work.
Depending on how you fare, I'm considering doing away with Qt warning crashes entirely. So what if it's a debug build; I don't really want Rosegarden crashing because of some trivial problem with a random data file that has minor consequences. If you're looking for that stuff, fine, but if you're not, it's just annoying as hell.
Rich: Can you make this happen again, but capture the console output (stdout/stderr) from rosegarden? It should have a message at the end that explains why the Qt connect() call is failing. If you could post the message(s) at the end, that should give us what we need to diagnose this.
Installing the "rosegarden" package instead of the "rosegarden-dbg" package should stop the crashing.
Michael: What's bizarre about this is that I added QT_FATAL_WARNINGS 8/28/2013 (r13381). The Ubuntu 10.04 version shouldn't be crashing at all. It might be that Ubuntu defines QT_FATAL_WARNINGS themselves in their "-dbg" builds. That would mean we have no control over it. Old versions will definitely crash because there were many connect() issues. Current rg is stable with QT_FATAL_WARNINGS defined. We fixed all the issues it brought to light.
I'd like to keep it since it points out problems when they are introduced. This can cut down on debugging time when there's a hard-to-spot typo in a connect(). But I can easily switch to adding it to my build process.
I got a lot on stout it would not pipe into a file, so I copied what I could from the terminal (see attached). Lots of missing font stuff and a few warnings about the midi clock, including one which said run sudo modprobe snd-rtctimer, which I did but it gave an error not found..
the relevant message appears to be
~~~~~~~~~~~
slotRescaleSelection: mult = 7680, div = 18426, ratio = 0.416802
[ProgressDialog] ProgressDialog::ProgressDialog - "Rescaling audio file..."
Object::connect: No such signal Rosegarden::ProgressDialog::cancelClicked() in src/commands/segment/AudioSegmentRescaleCommand.cpp:92
Aborted (core dumped)
~~~~~~~~~~~~
Also I don't have rosegarden-dbg installed, only rosegarden.
Last edit: Rich Rath 2014-08-12
Thanks, Rich, that's exactly what we needed. So, it looks like the test case is to do an Audio Segment Rescale and make sure the progress dialog is triggered. I'll see if I can reproduce. The simple solution will be just to comment out the connect() calls since the signal doesn't exist anyway. It looks like there may be about 4 of these throughout the system.
I'm still a bit confused as to why this warning would cause a crash in a release build. It would be nice to track down that mystery for future reference. Is there an environment var equivalent to QT_FATAL_WARNINGS? [It is an environment variable!] Does Debian/Ubuntu always build with QT_FATAL_WARNINGS? [It's not a #define, so I don't think this matters.] I'll do some digging and see what I can find.
Last edit: Ted Felix 2014-08-12
Got it. Test Procedure:
Fixed in r13776.
Rich: If you want to test the fix, you can build the latest rosegarden from SVN by following the directions you will find here:
http://www.rosegardenmusic.com/wiki/dev:eclipse
Let me know if you have any questions.
Silly me. QT_FATAL_WARNINGS is an environment variable. So, most likely what's going on here is that Rich's system happens to have that defined when he runs rg.
Rich, try running rosegarden from the command line like this:
Does that clear up the problem?
tried
same crash.
Last edit: Rich Rath 2014-08-12
I built from svn successfully, and went back to successfully squashing files. THanks! I did config with the debug flag left out. If I run into problems, I'll rebuild with the debug flag if needed.
not to hijack my own thread, but since you are around....I also get messages in the audio file manager about files encoded at 48k while RG is set to 44.1k Jack and all the files in question sound fine and jack is at 44k as are the files. the only odd thing about them is that they were recorded at 32 bits instead of 16 or 24. Everything sounds ok, so I have ignored them, but something is amiss. should I start a new thread for that?
Last edit: Rich Rath 2014-08-12
Great to hear. Let us know if you run into anything else.
I'll have a look around and see if I can shed some light on this for you.
Oh yeah... Let the record show that I took the time to test building production vs. debug with an intentional Qt error thrown in, and it all does work as it should. My suspicions were unfounded.
In regards to the audio issue... I was able to reproduce that message by launching jack at 48k then loading a composition with 44.1k audio files. JACK's default is 48k, so you might actually be launching JACK at 48k. Try this...
Close rosegarden, then from the command line, do this:
That should restart jackd at 44.1k. Leave that running. Now launch rosegarden either from another terminal or from the launcher. Load up your composition with 44.1k audio files, and you should be ok now. However, if you've been going back and forth between 48k and 44.1k, it's likely that you have a mix of 44.1k and 48k audio files since rg silently converts them to the current rate when you add them. The only fix for this is probably to re-add the offending ones. The audio file manager will point them out to make this easier.
If this fixes it, you might want to look into using qjackctl or the .jackdrc file to make sure JACK is really coming up at 44.1k every time.
ooops mised page 2. starting jack from cli. It is configured at 44.1 in qjackctl already though...
Last edit: Rich Rath 2014-08-12
Hi, started jackd from cli as noted, got same message (changed command from HW0 to HW1 for it to work).
main rosegarden window says following upon loading project:
then it gives a choice of:
I do not understand the choice, and it appears to have no effect either way. WHat does the choice mean? maybe language could be clearer.
Then when I go to audio file manager it gives the message in the attached image file.
Qjackctl is already configured at 44.1, and pretty much all my audio is at that sample rate, I never made the switch to a higher sample rate. There is no deterioration in the sound quality that I can perceive and I have pretty good ears and pretty good monitors. It seems like the message is getting triggered falsely by something, misreading the jack sample rate for whatever reason.
Last edit: Rich Rath 2014-08-12
.jackdrc=
/usr/bin/jackd -dalsa -dhw:Audio -r44100 -p128 -n3 -D -Phw:Audio -zt
Last edit: Rich Rath 2014-08-12
With a debug-enabled build of rosegarden, you should see this in the console
output when you run:
It will be after the "[ResourceFinder] Found it!" messages. That's what
JACK is telling us in response to a call to jack_get_sample_rate(). If
you are seeing 48000 when JACK is configured for 44100, then the problem is
in JACK.
Assuming the problem is with JACK...
What do the messages at JACK startup say? Do they indicate that the
rate is 44100? When you launch jackd from the command line, you should
see something like this:
There should be no error messages.
oops sorry to drop off on this. Jack starts with no errors in 44.1 k 16 bit, as per the command:
If there was a problem with jack it would turn up in other sound programs I run I would think. Everything else picks up the jack server at 44.1.
I built the latest snapshot with debug turned off. I will need to recompile and might not get to it for a little bit as I'll be super busy with work the next few days, but I'll recompile and post the output as soon as I can. THanks for sticking with this.
ok recompiled debug version. Attached the session. It initializes at 48000 even though jack is running at 44.1:
~~~~~~~~~~~
[RosegardenMainWindow] RosegardenMainWindow::isSequencerRunning: m_useSequencer = true , m_sequencerThread = QThread(0x1c37890)
JackDriver::initialiseAudio - JACK sample rate = 48000Hz, buffer size = 128
~~~~~~~~~~~~~~~~~~~~~~
and from jack startup:
~~~~~~~~~~~~~~
Acquire audio card Audio1
creating alsa driver ... hw:Audio|hw:Audio|128|3|44100|0|0|nomon|swmeter|-|32bit
ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to playback-only mode
configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 3 periods
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback
Triangular dithering at 16 bits
~~~~~~~~~~~~~~~~~~~~
nb: "Cannot open PCM device alsa_pcm for capture. Falling back to playback-only mode" is normal for this soundcard. It has no inputs. playback works fine. Again, the mismatch does not make any appreciable difference in sound quality, so I think rosefgarden is simply reporting wrong rather than actually working at 48k.
Last edit: Rich Rath 2014-08-18
Ok, so JACK claims to be starting at 44.1, but reports to rg that it is running at 48. There's probably not much rg can do to fix this as it sounds like the problem is related to JACK and/or your soundcard.
The "Cannot open PCM device..." message actually might be a clue. As you said, it might be because the card is one-way, however, more commonly it's an indicator that the wrong device name is being used which can cause all sort of odd trouble. I noticed that your device name (hw:Audio) is not one of the typical ALSA device names, like hw:0,0,1 or hw:2. This means you might be going through some stuff defined in your .asoundrc. I'm not sure that I'm going to be of much help at this point, however, we can poke around a little more to see if there are any other options for connecting to your soundcard. Can you post the output of: