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 CAA20970; Tue, 15 Jul 2003 02:37:44 +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 CAA21237 for ; Tue, 15 Jul 2003 02:37:42 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from www.duonix.com (duonix.com [210.113.163.221]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h6F0bfT02214 for ; Tue, 15 Jul 2003 02:37:41 +0200 (MET DST) Received: from hama ([192.168.0.254]) by www.duonix.com (8.12.8/8.11.6) with SMTP id h6F0kHjQ067993; Tue, 15 Jul 2003 09:46:17 +0900 (KST) (envelope-from shoh@duonix.com) Message-ID: <000801c34a69$51f8fec0$fe00a8c0@hama> From: "SooHyoung Oh" To: "Likai Liu" , Cc: "Likai Liu" References: Subject: Re: [Caml-list] PortAudio on ocaml Date: Tue, 15 Jul 2003 09:37:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 glance:01 threads:01 liu:99 api:01 callbacks:01 asmrun:01 byterun:01 implemented:01 callback:01 internals:01 stub:01 bug:01 faq:01 beginner's:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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" To: Cc: "Likai Liu" 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