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
