Even on my Intel Core i7 (2.8 GHz quad-core) I am able to get
Fluidsynth to cause xruns when playing really fast on a stereo piano
sound that I have (voice polyphony at 256). As I am playing fast
arpeggios with the pedal down, I can watch the jack dsp load (as
reported by Cadence) go higher and higher until a slew of xruns all
hit at once, ruining the sound. I have jack latency set at 2
buffers of 256 samples. I haven't tested this with older versions,
but it doesn't seem right to me that FluidSynth should fail like
this on such a fast processor. The CPU usage doesn't even seem to
be very high at all.
Here is the piano SoundFont I was testing this with: https://dl.dropbox.com/u/8126161/Splendid%20Grand-normal%20FluidSynth%20v2.tar.bz
You may keep the SoundFont for your own personal use, but please
don't spread it around. While the samples are in the public domain,
the sample programming was done for a commercial project, and I
don't think the copyright holders would be happy about me publishing
it online.
How to reproduce: Using the first preset in the SoundFont, hold down
the pedal and go nuts. When playing very fast (I have a master's
degree in piano performance), it doesn't take long for me to start
getting xruns.
Aere, how can I test the version from the PPA so I can compare?
Also, how do you pronounce your name? I'm just curious :)
Thanks,
-~Chris
On 08/02/2012 05:31 PM, Aere Greenway
wrote:
David and all:
I spent some time today trying to run the test on my 450 megahertz
machine. It was good that I did, in that I was able (finally) to
successfully run the test.
The release-candidate fluidsynth will not successfully play my
demo-pieces on a 450 megahertz machine, while your PPA for Ubuntu
11.10 (that I re-packaged for 12.04) plays it perfectly, and
without any under-runs. That's a pretty significant difference.
Here are the details of the testing I performed:
I first applied updates for anything with "pulse" (as in
pulseaudio) in it, as well as anything with "alsa" in it -
specifically libasound2.
I then tried running the test, but qjackctl still crashed.
I got some diagnostic information on it, but where you said there
is no dependency of fluidsynth on jack, I totally removed (purged)
jackd and qjactctl, and re-installed them.
I noticed in what got re-installed, it used jackd2, where your
build process seems to insist on jackd1. Also, your build process
seems to install development versions of jackd, but re-installing
used non-development versions.
After re-installing, qjackctl and qsynth initialized
successfully! So I was now in-business.
I then brought up Rosegarden, and played the demo-piece that
qsynth has been unable to play without your PPA version of
libfluidsynth1.
It start out okay, but within a few seconds, the sound that was
generated was crashing chords, one per second, with short pauses
in between each second. There were many under-runs, and the
system was performing sluggishly. It took me a quite awhile to
get the mouse cursor over to where I could click the Rosegarden
"Stop" button, and then it took awhile to finally stop.
I then followed your instructions on how to un-install the
release-candidate fluidsynth, restoring the original, and ran the
test again.
This time, it played flawlessly, though at the end, qjackctl
showed a few under-runs (which I hadn't heard).
I hadn't checked if the under-runs were there when I re-connected
Rosegarden to Qsynth, so I cleared the under-run count and played
it through again.
Before starting it, I noticed the "Reverb" check-box of Qsynth was
checked, which adds overhead (I don't even try the "Chorus"
check-box on slow machines). So before starting the piece, I
un-checked the "Reverb" check-box.
It played flawlessly all the way through, without a single
under-run. While it was playing, the RT-percentage displayed by
qjackctl was hovering around 70%.
Just to be thorough, I re-selected the "Reverb" check-box of
Qsynth, and played it through again.
It again played flawlessly, with no under-runs, though the
RT-percentage displayed by qjackctl was now hovering around 79%
(so reverb added about 9 percent to the real-time overhead).
My conclusions from the testing, are that the increased real-time
percentage I observed in my faster machine's Ubuntu partition was
indeed an indicator of big problems for slower machines. The
testing showed that the release-candidate fluidsynth could not
play the demo piece at all on a 450 megahertz machine.
I really hope that newer versions of fluidsynth will not abandon
slower machines altogether. If there are features that have been
added that are adding the overhead, it would be good to have some
way of turning these features off, rather than abandoning the
slower machines.
By the way, if you would like to test with this infamous demo
piece, I will be happy send it to you as an attachment, a MIDI
(.mid) file.
Also, it is good to be aware that another thing I configure
differently to avoid overhead on slower machines, is to set the
polyphony parameter to 64 (rather than the default of 256).
On the faster machine (the Ubuntu partition) that succeeded in
playing the piece, I also limited the polyphony configuration
value to 64.
Now that I can run the tests on that machine, please let me know
if there is further testing you would like me to run, or if you
have a fixed-version to test.
- Aere
On Thu, 2012-08-02 at 17:55 +0200, David Henningsson wrote:
On 08/02/2012 07:45 AM, Aere Greenway wrote:
> David:
>
> I ran the test on a partition I was planning on replacing (to minimize
> risk to my other testing).
>
> A side-effect of that decision, is that it was done on a non-updated
> system. In fact, the crash-report generated for it, indicated it wasn't
> reportable because of an obsolete version of libasound.so (or something
> like that).
>
> I didn't update it because updates on a 450 megahertz machine take a lot
> of time, and I was going to replace the partition anyway.
>
> It seemed to me (as I watched the build process) that it was complaining
> about jackd1 vs. jackd2.
Please verify that you're still running the jack version you expect. If
the build process switched jack version for you, you can switch it back
(just install the right version again). This is just because the
development package is not switching as well as the library package in
Debian. FluidSynth can run against either version.
> But when I went to get the listings of the
> build process, the file (written by abiword, which also had significant
> problems in this release) had somehow been garbled, and could not be
> read by Libre Office - so I lost my build listings!
>
> I am pretty sure the build process was what caused problems for
> qjackctl, because I only use that machine for testing, and the last
> thing I (most likely) did on it was the same test I was trying to run
> with the new fluidsynth. I'm sure it was successful before, because I
> always run those tests on new systems.
>
> I did not manually copy any '.so' files.
>
> Here is what I was able to collect of the problem:
>
> address@hidden <mailto:address@hidden>:~$ gdb qjackctl
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.launchpad.net/gdb-linaro/>...
> "/usr/bin/qjackctl": not in executable format: File format not recognized
Hrm, next time instead run "gdb /usr/lib/qjackctl/qjackctl.real", as
qjackctl is a wrapper script. :-/
> (gdb)
>
> FROM QJACKCTL MESSAGES:
>
> 12:37:43.266 Patchbay deactivated.
> 12:37:43.361 Statistics reset.
> 12:37:43.659 ALSA connection change.
> 12:37:43.751 D-BUS: Service not available (org.jackaudio.service aka
> jackdbus).
> 12:37:43.828 JACK is starting...
> 12:37:43.831 /usr/bin/jackd -dalsa -dhw:0 -r44100 -p1024 -n2
> 12:37:43.905 ALSA connection graph change.
> 12:37:43.908 JACK was started with PID=1670.
> jackd 0.121.2
> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn
> and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> JACK compiled with System V SHM support.
> loading driver ..
> apparent rate = 44100
> creating alsa driver ... hw:0|hw:0|1024|2|44100|0|0|nomon|swmeter|-|32bit
> control device hw:0
> 12:37:48.293 Server configuration saved to "/home/aere/.jackdrc".
> 12:37:48.325 Statistics reset.
> 12:38:06.453 Client activated.
> cannot read result for request type 6 from server (Connection reset by peer)
> cannot read server event (Success)
> cannot continue execution of the processing graph (Bad file descriptor)
> cannot continue execution of the processing graph (Bad file descriptor)
> cannot continue execution of the processing graph (Bad file descriptor)
> cannot continue execution of the processing graph (Bad file descriptor)
> cannot continue execution of the processing graph (Bad file descriptor)
> cannot continue execution of the processing graph (Bad file descriptor)
>
> FROM CRASH REPORT (COPIED BY HAND):
A tip could be to take a photo with a digital camera / phone instead of
hand-copying - it's up to you what you find simplest.
> jackd crashed with signal 7 in pa_shm_create_rw
>
> StacktraceTop
> pa_shm_create_rw() from /usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
> pa_mempool_new() from /usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
> pa_context_new_with_proplist() from /usr/lib/i386-linux-gnu/libpulse.so.0
> pa_context_new() from /usr/lib/i386-linux-gnu/libpulse.so.0
> conf_pulse_hook_load_if_running() from
> /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_conf_pulse.so
This is related to alsa-plugins or pulseaudio, not fluidsynth. If
upgrading *everything* is hard, you should try upgrading at least all
packages beginning with "pulseaudio", "libpulse" or "libasound". I saw a
Launchpad bug with the same stack trace, and the bug reporter said it
was resolved with an update.
> Please be aware that I consider the testing (done on an Ubuntu
> partition) to have been successful. I just wanted to find out if the
> increased overhead causes it to no longer work on my slowest machine.
Ok.
// David
_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev
|