I think some instruments are missing too. Certain sounds in TamTam do not work,
such as the "laugh" sound. TamTam prints this message:

insert_score_event(): invalid instrument number or name


If I rebuild the csound we shipped in Fedora7 on Fedora 9 then the "invalid
instrument" and the "WARNING: couldn't open library" messages go away.

Created attachment 312153 [details]
disable hetro

This patch solves the hetro_init warning - hetro is excluded from OLPC builds

The reason for the bad libogg link is because the build does this:

gcc -o libogg.so -Wl,-Bdynamic -shared Opcodes/ogg.os -L. -L. -L/usr/local/lib
-L. -L. -L/usr/lib/fltk-1.1 -lsndfile -lasound -llo -lsndfile -lvorbisfile
gcc -o liboggplay.so -Wl,-Bdynamic -lvorbisfile -lvorbis -logg -shared
Opcodes/oggplay.os -L. -L. -L/usr/local/lib -L. -L. -L/usr/lib/fltk-1.1
-lsndfile -lasound -llo -lsndfile -lpng -lz

i.e. it creates a file called libogg.so in the current directory, then creates a
library called liboggplay.so and compiles with "-L. -logg", causing it to link
against the csound libogg plugin rather than /usr/lib/libogg.so.0

I'm not sure how to best attack this given my very limited knowledge of SCons

I'll look into fixing these ASAP. Are they fedora-9 only or they are 
happening on fedora-7/XO as well?
The insert_score_event problem might be a bug on 5.08, in the API call
csoundScoreEvent(), I had another, unrelated, report of this. I'll check.

They are Fedora 9 only - we are using csound-5.07 in F7 and we aren't developing
that branch any more. (Perhaps the same bugs would occur if we backported
olpcsound-5.08 to F7, but that's not going to happen)

They are not on F7 as I have built and ran the installation there. I'll
work on this and see where I get.

I checked out the

insert_score_event(): invalid instrument number or name

problem and diagnosed it. This is caused by using a doubles
version of Csound5 library mixed with a single-precision 
executable/host (or the other way round). The score event 
array gets passed as float (or double) and the csound lib
expects it as double (or float).

I will later look why this has arisen in the olpcsound package
at all (it should not have). Would it be possible that you
had two versions of _csnd.so (the binary csnd Python module) 
in your system?

There is just one _csnd.so on the system (freshly reflashed) at
/usr/lib/python2.5/site-packages/_csnd.so

Is single vs double precision a case of 32 vs 64 bit, or does the precision vary
on 32 bit systems alone? I am wondering whether TamTam's _aclient.so module
(which interacts with csound) has been compiled with double precision (how can I
check?)

Thanks!

The precision is set by an scons option (useDouble, setting
-DUSE_DOUBLE) and affects how floating-point data is 
represented inside Csound. This is independent of the OS.
But in the case of csound and OLPC, 
I think all packages have always been built single-precision. If you
look at Koji's build logs, you will see whether this
is the case, because scons reports it. 

As far as _aclient.so is concerned, I suppose you need to ask
who packaged it. 
 

koji build logs say:
CONFIGURATION DECISION: Using single-precision floating point for audio samples.

/usr/lib/python2.5/site-packages/_csnd.so is unrelated to this problem because
TamTam's aclient.so uses libcsound directly. TamTam is usable (except for the
instruments that exhibit this bug) even when I have deleted this file.

I was the last person who compiled aclient.so, with these flags:

g++ -I/usr/include/python2.5 -Wall -fPIC -O2 -finline -shared -o aclient.so
aclient.cpp -lasound  -lcsound -lpython2.5

...but I do not think the problem is in aclient, because if I remove
olpcsound-5.08 and install csound-5.07 then the instruments start working with
the very same aclient.so

closing old/stale bug - we now use csound and it is working.