CCRMA

From the ALSA wiki

CCRMA stands for Center for Computer Research in Music and Acoustics. For detailed information look on their official web site: http://ccrma.stanford.edu/planetccrma/software/

[edit] 2005-12-14 - Thanks and Where should this go

Thanks for this wiki; I was about to send this to the lau list but I think it may be better on this wiki. But I don't know if it's suitable or where it should go. I'm using PlanetCCRMA? rh9 recently updated and have been for a long time. I use this system to support a group of musicians who meet and pratice. Using SBlive with hardware soundfont loaded for midi keyboard. We meet play and record (using the sblive linein from a mixer) with audacity just to hear how it sounds and hopefully improve our playing. We play back using alsaplayer and also use it for some internet radio. All works great if, and only if, I do the following when I boot the machine.

First log on as me, startx, start realplayer and start playing some internet radio link. Then, use sfxload to load the soundfont. If I do this then I can start an instance of alsaplayer and play some tune mixed with the realplayer output. And start second alsaplayer instance, play that ... I can start or stop realplayer or any alsaplayer instance.

If after logging on, I startx, load the soundfont, alsaplayer works, but only if no other instance of alsaplayer is up and realplayer is not up. If alsaplayer is running, then another alsaplayer will not start, nor will realplayer, audacity and so on.

sfxload, realplayer and audacity are all use the OSS sound system, most likely via ALSAs OSS emulation layer, so perhaps the OSS emulation modules are not being loaded correctly unless you get your start sequence just right.

Note I'm not asking why (but I am wondering); I mainly want to get my "startup routine" posted where others SBlive;RH9 users can see it and add to it. So thanks to all who contribute here. Please move this to where it sould be (or delete it if it's oldnews).

It's more of a CCRMA issue and I suspect the best advice would be to install or upgrade to a later version.

Also, please comment on whether I can expect the same behavior when/if I upgrade to ccrma fc3 or 4.

To really nail this down I suggest you go to the main CCRMA site and signup to their users mailing-list and ask this question there. You may get this issue sorted out and any others that crop up in the future. Fell free to add the solution or any notes to this page.

http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

[edit] 2005-01-22

A note from Fernando Lopez-Lezcano on the ALSA Users mailing-list about CCRMA kernel modules: For a normal Planet CCRMA FC2/3 install there are two locations for the ALSA kernel modules. One is the one that comes with the kernel itself. But Planet CCRMA also supplies a more up to date version of ALSA, and those kernel modules are installed in:

/lib/modules/`uname -r`/updates/

They override (ie: they are first in the modprobe search order) the ones in the kernel. So if you do a normal alsa kernel modules install you will overwrite the modules in the kernel tree, not the updates, and then if you reload the module you will still get the one in the "updates" directory.

So... you want to overwrite the updated modules, and you can do that by supplying the proper flag to the alsa driver configure process:

--with-moddir=/lib/modules/KERNEL_VERSION/updates

With this added the install will overwrite the updated modules (installed through the kernel-module-alsa package for your kernel version). A subsequenct /sbin/depmod -a and /sbin/modprobe whatever should bring in the new version (provided you unload the modules first, of course).