Bernd: FluidSynth (Qsynth) has responded to the sustain pedal as far back as when I started using it (Ubuntu 8.04, and even earlier).
- Aere On Sat, 2012-08-04 at 09:35 +0200, BCA wrote: > 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 -- Sincerely, Aere
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
