The short version: If a haskell routine exported to C is called from a CoreAudio IO Proc, which is on a separate thread than the main thread, the Haskell routine seams to exit early without notice. If the same routine is called from the main thread the routine produces correct output. Any ideas on why
Storeable.poke* would cause problems in this situation?<br><br>The long version:<br clear="all">I'm attempting to generate audio using Haskell and CoreAudio.* For a start I tried converting Noel Cragg's HAL sinewave demo to process the audio frames in Haskell. The original is here:
<br><a href="http://www.red-bean.com/~noel/audio/hal-demo.c">http://www.red-bean.com/~noel/audio/hal-demo.c</a><br><br>How CoreAudio HAL output works is like this:<br>- A audio callback is registered with the audio device
<br>- Audio playback is started<br>- A separate thread, dedicated to audio processing, will then call the audio callback with pre-allocated buffers to be filled out with audio samples.<br><br>The test program has "main" in C and the audio callback in C. The C callback forwards to a Haskell routine exported by the FFI system. This routine should behave identically to the C implementation that already exists. However, the routine does not work correctly if called from the audio thread.
<br><br>The test program also calls the routine from the main thread in a manner that should be identical to how it's called from the thread. This is used to verify the Haskell callback does actually produce the same audio as the original C callback. So I know the code should work, but just fails for some inexplicable reason on the threaded callback.
<br><br>Other notes:<br>- The program is compiled with -threaded and linked against the threaded RTS.<br>- If I structure the routine like this:<br> ...<br> print "Before the audio is written to the buffer."
<br> process_frames<br> print "After the audio is written to the buffer."<br><br>The first print succeeds but the second print never occurs. No IO error is reported to try_.<br>- If I take that same structure and remove "pokeElemAt" from process_frames. The second print occurs.
<br><br>I've uploaded the test program here:<br><a href="http://www.tothepowerofdisco.com/downloads/TestAudioOutput.zip">http://www.tothepowerofdisco.com/downloads/TestAudioOutput.zip</a><br><br>Some notes on if you actually try to build it:
<br>- You have to build 3 times; There is a bug in XCode's custom build rule handling or the projects custom build rule. <br>- The executable is wrapped in a app bundle but is actually a command line app.<br>- It's a hack and I'm a beginner so comments are scarce and some code may be strange. ;-)
<br>- Assumes ghc 6.6 is installed to /usr/local<br><br>Any ideas?<br>-- <br>-Corey O'Connor