]> I didn't read your message seriously, but in my first glance, what you want to seems to be asychroneous threads. Why don't you use Event module of threads library? It's a Concurrent ML. --- SooHyoung Oh ----- Original Message ----- From: "Likai Liu" <liulk@bu.edu> To: <caml-list@inria.fr> Cc: "Likai Liu" <liulk@acs.bu.edu> Sent: Tuesday, July 15, 2003 5:55 AM Subject: [Caml-list] PortAudio on ocaml > 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 > ------------------- 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