[Caml-list] PortAudio on ocaml

[Likai Liu <liulk@bu.edu>]

Hello,

I'm trying to evaluate on porting PortAudio API to O'Caml, which would
enable an entire genre of sound applications being written in this nice
language. What concerns me is that PortAudio uses asynchronous callbacks,
much like signals, to tell the application that some audio sample has
arrived, needs to be played, or both. I looked at the signal.c of asmrun
and byterun and found out that signals are normally deferred if it
interrupts a running O'Caml program until a garbage collection cycle
occurs. It doesn't seem fesible to have these real-time audio callbacks
implemented this way; threads seems to be the only way.

If I were to enforce using threads semantics, then the synchronization
issue might have some light. However, the original PortAudio API is meant
for a program to continue its execution when callback keeps coming.
Depending on the implementation on a certain platform, it might interrupt
the program completely while it processes the callback, or the program
might run concurrently with the callback on different threads. Since only
one O'Caml section can hold the global mutex lock at any given time, it's
likely that the callback will block trying to acquire the lock in either
cases. It seems necessary to change the PortAudio interface on O'Caml to
block the running program while the audio transaction is carried out.

Before I make such a radical decision, I'm wondering if there is a better
solution. A possibility after soul searching the source code of threads is
that, in the case of bytecode, when a thread does Unix.select, the thread
scheduler would let go the lock momentarily so the callback doesn't block
forever; in the case of native thread, when a thread calls Threads.yield,
then the lock is released momentarily. I'm not sure if it's a good idea to
rely on these deep internals of O'Caml, or maybe it's better to stay on
the light side, that is, restrict the API for workaround, instead. What do
the O'Caml developers say about this?

There is a simplified interface of PortAudio called Pablio that doesn't
use the callback, but a conventional blocking I/O style read/write
functions. Pablio interface is straightforward to implement. So at least
the current plan is to get pablio working first, and leave the actual
PortAudio API unimplemented with some provided interface stub for
reference purpose.

liulk

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners