Re: Keeping real-time instruments alive

From: John Lazzaro (lazzaro@cs.berkeley.edu)
Date: Fri Jul 14 2000 - 20:33:55 EDT


> 1) By default, real-time performances seem to die after about
> a minute or so.

This was done to prevent runaway SAOL programs writing to disk
from filling up the disk inadvertantly. The easiest way to
get effectively infinite play time is by using a one-line SASL
file that's an end command -- for example, if you look in the
sfront/examples/linbuzz.sasl file, you'll see:

216000.0 end

Carefully chosen so that the number of kcycles it represents
fits into a 32-bit signed integer, there was (and may still
be, actually) a bug in sfront when you used end times which
didn't fit ...

sfront -gcc -cpp -Is ../../../lib -latency 0.002 -playback -aout linux -cin linmidi -orc linbuzz.saol -sco linbuzz.sasl

Shows how linbuzz uses the sasl file ...

Note that there's one risk here when you use long endtimes --
if you're running as root using -timesync mode, and there's
an sfront bug (which I believe there is not, but you never
know ...) involving the dead-man system that releases SCHED_FIFO
mode when you don't play MIDI notes for 5 seconds, then instead
of your machine locking up for 60 seconds or 10 minutes, it
will lock up for 216000.0 seconds, pretty much forcing you to
do a hard reboot, with the possibility of file system damage,
ect. So, picking a compromise number like an hour might be
better, so you can wait out any freeze that might happen due
to a bug.

> 2) I was not able to get the -ain std option to work.

What's going on here is that -ain std expects signed 16-bit
shorts in the byte-order of the machine as input, not a
foo.wav file. The easiest way to figure out how to use this
option is via the examples/beat and examples/in examples.

[1] cd to examples/beat, and set these environment variables

setenv OUTFILE std
setenv REDIRECT "> output.raw"

Then do

make -e

You'll see:

sfront -fixedseed -aout std -orc beat.saol -sco beat.sasl
sfront, a SAOL to C translator. Version --IDSTRING--.
Run sfront with -license option for Copyright/License info.

gcc -O3 sa.c -lm -o sa
./sa > output.raw
cp std ../in/input.wav
cp: std: No such file or directory

Do an ls and you'll see

stdout.info output.raw

Do this:

mv stdout.info ../in/stdin.info
mv output.raw ../in/input.raw

Then cd into examples/in, and set these environment
variables:

setenv OUTFILE output.wav
setenv INFILE std
setenv REDIRECT "< input.raw"

make -e
sfront -aout output.wav -ain std -orc in.saol
sfront, a SAOL to C translator. Version --IDSTRING--.
Run sfront with -license option for Copyright/License info.

gcc -O3 sa.c -lm -o sa
./sa < input.raw

Finally, play the output.wav and see the results.

A quick look in the stdin.info file:

% more stdin.info
44100
2
5292168

The first line is the sample rate, the second line is the
number of channels, the third line is the number of samples
to process. If I remember correctly, this file isn't
strictly necessary -- if you

-- set the srate global parameter (or let it default to 32000)
-- set the inchannels parameter (default of 0 isn't useful ...)

Things should just run indefinitely if you select -ain stdin;
the in.saol example doesn't set inchannels on purpose, so it
can test the "auto sample-rate and inchannel detection" code
(which for -ain input.raw and -ain std, looks for a input.raw.info
and stdin.info file, respectively).

This is all documented for raw files, but I forgot to document
this for the std option, it seems (the auto sample-rate code
is pretty new ...).

                                                        --jl

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:40 EST