Achieving satisfaction...

... being an account of my adventures in getting Csound 5 up and running on my Ubuntu Linux system.

I've never really moved from Csound 4 to Csound 5 to this point, because for one thing 5 doesn't run on BeOS, which is my main system. (There's no real reason it can't run there, except for getting scons all set up, and probably some updating of the real-time connectivity. I started on scons at one time, but never got all the way there.) Anyway, now that I have Ubuntu Linux on my other box, I thought that I should at least be up-to-date there.

My first approach, a few months ago, was to download the compiled 5.08 package for Ubuntu, but I wasn't happy with this at all. For one thing it was unuseably slow -- unable to play more than a few notes of my Rotor Organ at a time, while my old Csound4 on the same machine had no trouble with anything I could play. I suspected that this was because the only version in the Ubuntu repository is the 'double' version. I don't see any personal need for this, but out of the box I had no choice.

The default PortAudio and PortMidi were very confusing on my system, with some of the listed devices working properly, others not. In any case, I want to simply stick to ALSA on this box, but Csound wouldn't talk to that at all! Setting '-+rtaudio=alsa' always gave the error "Unable to set sample rate on card".

My next step was to get the 5.08 sources, and compile it myself -- the single precision version. I still couldn't get ALSA to work, though, and I put the project aside.

Seeing 5.10 released, I thought it was time to try again. Once more I began by downloading the precompiled (SUSE) package, but after trying to use the installer on that (!) I said to heck with it -- I'll build my own. [I dislike installers at the best of times, but that "Fast Light" one is the worst I've ever seen -- no help, no listing of what it's going to do, where it's going to put files, and so on. Bah!]

The actual build involved some false starts, deciding what options were suitable and so on, but really was pretty smooth. In fact the final command-line was
"scons dynamicCsoundLibrary"
Everything else I'd tried -- like "useALSA" turned out to be superfluous.

There was just one big problem -- ALSA still didn't work! I always got the "Unable to set sample rate" message. And yet fluidsynth didn't have any trouble with ALSA. So I dug into the sources of both, and found that there are two ALSA API calls one could make to set the rate; Csound used one, fluidsynth the other! The first requires an exact rate value, which apparently "44100" does not qualify as, but the other finds the nearest rate that the card is capable of (which on my es-1371 seems to be still "44100" but I guess not quite...). I rewrote that line of rtalsa.c to match the working code and have had no more problems.

I should report this to the bug-list at sourceforge, I guess. I'm pretty sure the fix doesn't break anything.

One other gotcha I ran into was that -- without the "buildRelease" scons option -- OPCODEDIR has to be set. The source code handling of this seems to be a bit strange (not suitable for Windows for instance), so I just punted and patched that source (csmodule.c) as well to force a default.

After all that, everything I've tried works fine. It's just as fast as C4, ALSA audio and MIDI work as advertised, and I'm happy. The plugin system is a big advance: in fact I didn't really have to compile anything except the modules I changed; everything else can be obtained from the precompiled version and slots straight in. The only thing I wish is that there was some build option to make ALSA the default, so the command-line didn't always have to include "-+rtaudio=alsa -+rtmidi=alsa".

Sorry about the rambling, but then my journey was pretty erratic as well!

replies ...

I've never really moved from Csound 4 to Csound 5 to this point, because for one thing 5 doesn't run on BeOS, which is my main system.

When the decision was made for Csound 5 to only officially support Windows, Linux, and Mac OS X, I was a little concerned that people on Solaris, BSD, Irix, BeOS, etc. would be stuck with Csound 4. I believe that there are now some spots in the code with #ifdefs that really assume one of those three platforms, and on "something else" you may sometimes get the Linux code, other times the Windows code, etc. This is unfortunate ...

So I dug into the sources of both, and found that there are two ALSA API calls one could make to set the rate; Csound used one, fluidsynth the other! [...] I rewrote that line of rtalsa.c to match the working code and have had no more problems.

I should report this to the bug-list at sourceforge, I guess. I'm pretty sure the fix doesn't break anything.

Yes, please do report this to the Csound mailing list!! (The Sourceforge Tracker is not used very much). Or I can pass it on to the developers for you. Just send me some more details please.

The only thing I wish is that there was some build option to make ALSA the default, so the command-line didn't always have to include "-+rtaudio=alsa -+rtmidi=alsa".

You can put your own default options into a file named ".csoundrc". This file is searched for whenever Csound is run – I believe first in the current directory, then your home folder.

Hope that you enjoy Csound 5!

- Anthony

Code Patch

When the decision was made for Csound 5 to only officially support Windows, Linux, and Mac OS X, I was a little concerned that people on Solaris, BSD, Irix, BeOS, etc. would be stuck with Csound 4.
When I get time (and disc space, and motivation!), I'll try to continue the port of Csound 5 to BeOS (soon to be "Haiku"... (:-)). I'll of course feed back whatever I find and do.

Yes, please do report this to the Csound mailing list!! (The Sourceforge Tracker is not used very much). Or I can pass it on to the developers for you. Just send me some more details please.
Hmm, I don't think I want to join another mailing list at this point (I find that mail starts to accumulate unread), so if it's OK I'll just pass the simple change on to you.
I'll try to attach the updated source -- uhh, no I can't, so here's the diff command output (hopefully understandable despite possible line folding):
diff InOut/rtalsa.c_ORIG InOut/rtalsa.c
21a22,23
>
> 09/03/04 -- sample rate setting changed to '..._near(...)' call
367,369c369,371
< /* sample rate, */
< if (snd_pcm_hw_params_set_rate(dev->handle, hw_params,
< (unsigned int) dev->srate, 0) < 0) {
---
> /* sample rate, (patched for sound cards that object to fixed rate) */
> if (snd_pcm_hw_params_set_rate_near(dev->handle, hw_params,
> (unsigned int *) &dev->srate, 0) < 0) {

Note the slight difference in the actual rate parameter -- a reference in the revised call. This may change the actual value in the 'dev' structure -- don't know if that could have any external effect. Doesn't appear to in my case. (fluidsynth reports that it "may be out of tune", but again in my case it's not.)

You can put your own default options into a file named ".csoundrc". This file is searched for whenever Csound is run – I believe first in the current directory, then your home folder.
Yes, of course I should have thought of this. Thanks.

z pak ed drugs zpak Canadian pharmacy viagra viagra uk pharmacy uk buy zithromax generic viagra generic cialis cheap generic viagra Canadian pharmacy cialis uk kamagra uk viagra online ed pills z-pak buy viagra uk z-pack z pack staxyn zpack cialis online avanafil