Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] PortAudio on ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-07-15 (00:37)
From: SooHyoung Oh <shoh@d...>
Subject: Re: [Caml-list] PortAudio on ocaml

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, 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 Archives:
> Bug reports: FAQ:
> Beginner's list:

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: