jurgen wrote: No, I haven't, as of yet.... This is because it wasn't clear to me whether this is an OS issue. The tricky thing here is that I changed 2 major things at the same time: the OS, and the way Qsynth was utilised (as in, 3 engines instead of 1, many more soundfonts, some never tried before, sometimes 3 running concurrently, in the backdrop of heavy CPU usage). And I've noticed this new phenomenon, and don't know which change to attribute it to. OTOH, even if the OS is doing something in the background and causing the delay, isn't the onus of at least reporting it (as an xrun/lost note/dropped packet... sorry, don't know the right term) upon the application (in this case, qjackctl/qsynth)? One more thing: I noticed that with 3 qsynth engines running together, not all would show up in the qjackctl connections window at startup. I'd have to restart 1 or more, and this was a dicey thing: sometimes happens, sometimes doesnt, for the same setup, upon restarting the jack server. Which is why I'm a little more suspicious about the apps rather than the OS... but I am open about this. If it is a good idea, then I will check on the AVLinux forums as well. Cheers, Guru

Hello everyone, Finally! Here's a quick update on my fluidsynth issues. I figured there has to be a better way of stress testing the system than physically banging my midi controller. I created a simple file in rosegarden , equivalent of hitting 88(?)keys repeatedly in a loop, with the sustain pedal on; I've attached the rosegarden file. It would be nice if people could post results of using this file (or a more suitable one!). Here are some of the initial (and very interesting) results (core 2 macbook running AVLinux): Using 2 qsynth engines, each containting multiple soundfonts (around ~200 MB), at higher speeds (above 360 BPM), fluidsynth (qsynth in this case) crashes with this error in the qjackctl messages window: subgraph starting at qsynth timed out (subgraph_wait_fd=32, status = 0, state = Finished, pollret = 0 revents = 0x0) Sometimes, not just qsynth, but other applications, such as jack-rack or rosegarden also crash with the same error. So not only does fluidsynth itself crash, it can potentially drag down the whole ship with it! To answer Lee's question, yes and no. Most of the times, I can restart the qsynth engines and everything's back to normal, but occasionally, I have to restart jackd itself. For some soundfonts (including my "bread and butter" ones :( ), running the loop at 720 BPM guarantees an (almost) instant crash, within around a second. Yes, the crash corresponds to cpu usage spikes of ~50% (at least). Of course, the stress test is unreasonably demanding, but eventually, that kind of extreme stress will be encountered. For a live musician, an application that cannot deal with it is simply unreliable. Bottomline: Using soundfonts on linux system for a live performance is a bad idea. On the other hand, I ran the same thing against ~900 MB piano sample on Linuxsampler. Perfectly stable at 720 BPM. Of course, I can't percieve dropped notes, and there are no xruns reported, but still.. it doesn't crash!!! (This ties in with Dominic's observation of 'better' performance of LInuxsampler vis-a-vis Fluidsynth). Which brings me to ask: what does it mean for a subgraph to "time out"? Understandably, a given audio application can't be expected to perform under any cpu load. But why can't fluidsynth just drop notes and move on? Are there any simple workarounds for subgraphs timing out, or is it an inherent bug in the fluidsynth libraries? The strong feeling that one gets is that fluidsynth has simply not been designed with failsafes in mind, for extreme situations. Also, are there fluidsynth developers who are on this list? If not, is there a better forum to give them feedback regarding these issues? Given the availability of decent to good soundfonts, and the number of man-hours put in by various developers on applications like qsynth and ghostess, it is truly unfortunate that the base fluidsynth library itself is inherently unusable in live contexts. Cheers, Guru (P.S. I do hope I'm not jumping to conclusions here. If someone can show that the problem lies not with fluidsynth but some other application, I'd be happy to be corrected. But that there is a serious problem somewhere, there is little doubt!) On Sun, Nov 8, 2009 at 12:38 PM, Guru Prasad B. R. <prasadbrg(a)gmail.com>wrote;wrote: