Does CoreAudio use the alarm signal in the IO proc thread?
Does CoreAudio use the alarm signal in the IO proc thread?
- Subject: Does CoreAudio use the alarm signal in the IO proc thread?
- From: "Corey O'Connor" <email@hidden>
- Date: Tue, 23 Jan 2007 13:59:00 -0800
I'm trying to figure out why I cannot use Haskell from a CoreAudio HAL IO proc. One thing Haskell does, which is questionable IMO, is use the alarm signal for it's own thread scheduler. The program is behaving as if the Haskell code is terminating early, but only in the HAL IO proc thread. I think this would be consistent with the Haskell code
triggering a signal but instead of the Haskell scheduler recieving the
signal another signal handler is triggered. Is it possible that CoreAudio registers it's own signal handler in the IO proc thread? Or are there other caveats to the CoreAudio realtime thread that would account for this behavior?
I'm still in the process of tracking down what is causing the early termination of the haskell code, but I thought I'd ask just in case. :-)
For additional background I included my post to a Haskell-specific mailing list:
---------- Forwarded message ----------
From: Corey O'Connor <email@hidden>
Date: Jan 21, 2007 12:24 PM
Subject: Problems using Storable.poke* from separate OS thread.
To: email@hidden
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?
The long version:
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:
http://www.red-bean.com/~noel/audio/hal-demo.cHow CoreAudio HAL output works is like this:
- A audio callback is registered with the audio device
- Audio playback is started
- A separate thread, dedicated to audio processing, will then call the audio callback with pre-allocated buffers to be filled out with audio samples.
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.
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.
Other notes:
- The program is compiled with -threaded and linked against the threaded RTS.
- If I structure the routine like this:
...
print "Before the audio is written to the buffer."
process_frames
print "After the audio is written to the buffer."
The first print succeeds but the second print never occurs. No IO error is reported to try_.
- If I take that same structure and remove "pokeElemAt" from process_frames. The second print occurs.
I've uploaded the test program here:
http://www.tothepowerofdisco.com/downloads/TestAudioOutput.zip
Some notes on if you actually try to build it:
- You have to build 3 times; There is a bug in XCode's custom build rule handling or the projects custom build rule.
- The executable is wrapped in a app bundle but is actually a command line app.
- It's a hack and I'm a beginner so comments are scarce and some code may be strange. ;-)
- Assumes ghc 6.6 is installed to /usr/local
Any ideas?
--
-Corey O'Connor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden