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 ----- Absender: S. Christian Collins Empfänger: fluid-dev 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.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: > > aere@Aere-HP-Vectra <mailto:aere@Aere-HP-Vectra>:~$ 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 -- Sincerely, Aere _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
