I'm still under the impression, the significantly higher CPU usage (and the
resulting slight sluggishness of instruments being in crisp response before) was
introduced with the enhanced voice-stealing algorithm, implemented by David. It
was - IIRC - coming with version 1.1.4.
BTW - how do I address sustain pedal in FluidSynth? I thought CC64 is not
implemented yet, in FluidSynth?
Best
Bernd.
-----
Folgende Nachricht wurde empfangen -----
Zeit:
2012-08-03, 15:39:25
Betreff:
Re: [fluid-dev] Proposal: FluidSynth tester program
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.bzYou
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
|