[Help-gsl] new alsa stuff

[James Bergstra]

I have got the alsa stuff working here.  It's first-draft code, and could use
some reorganizing and polishing, but the technique is there and it works.

Using this code implies several new possibilities:

- We can disconnect from alsa without changing anything in csound... we don't
  need to kill csound in any sense.

- There is some minor performance improvement by writing csound's float buffer
  directly to hardware.  Maybe the chip can convert float samples and we save
  computation time.

- We can accurately the onset and duration of buffer underruns and react
  accordingly, to maintain synchronization between networked TamTams.

- I added the possibility to reschedule the sound-rendering thread.  This only
  works when we run tamtam as root, but it makes a *HUGE* difference to
  performance.  For example, in this mode I used a double buffer system of 2 * 
256
  samples and achieved totally solid playback over three pages full of notes,
  which I have never seen before.  So this idea has potential to be a real
  solution. Jean, you've got to talk to the OLPC guys and get them to either
  help us engineer this better, or let tamtam run with realtime priority.

- Using 2 * 256 buffers means a certain amount of latency.  The time a sample
  spends in the sound buffer is between 16 and 32 milliseconds.  That doesn't
  include the latency induced by passing it through X, gtk, python, and finally
  to the sound-rendering thread.  There is a lot of room for improvemnt in this
  respect, but I haven't got muhc in the way of ideas yet...

- I haven't implemented the microphone input yet.

- The new system involves writing a multiple of ksmps to the sound buffer, so
  ksmps has to be a power of two.  It is sitting now at 64.


I'll try to get the microphone implemented first, so that the new code is a
feature-wise match of the old code... then I'll push, hopefully later this week.

Good tamtam session, 

J
-- 
http://www-etud.iro.umontreal.ca/~bergstrj