From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA14496; Mon, 14 Jul 2003 22:55:48 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA16189 for ; Mon, 14 Jul 2003 22:55:46 +0200 (MET DST) Received: from acsn03.bu.edu (acsn03.bu.edu [128.197.159.63]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h6EKtjT25759 for ; Mon, 14 Jul 2003 22:55:46 +0200 (MET DST) Received: from localhost (liulk@localhost) by acsn03.bu.edu ((8.9.3p2.buoit.v1.3)/BU_Server-1.3) with ESMTP id QAA158488; Mon, 14 Jul 2003 16:55:45 -0400 Date: Mon, 14 Jul 2003 16:55:44 -0400 (EDT) From: Likai Liu To: cc: Likai Liu Subject: [Caml-list] PortAudio on ocaml Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: caml-list@inria.fr X-Spam: no; 0.00; liu:99 api:01 callbacks:01 asmrun:01 byterun:01 implemented:01 threads:01 callback:01 internals:01 stub:01 asynchronous:01 semantics:01 ocaml:01 garbage:01 blocking:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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