Re: Does CoreAudio use the alarm signal in the IO proc thread?
Re: Does CoreAudio use the alarm signal in the IO proc thread?
- Subject: Re: Does CoreAudio use the alarm signal in the IO proc thread?
- From: Jeff Moore <email@hidden>
- Date: Tue, 23 Jan 2007 14:17:09 -0800
The HAL does not use signals. In fact, I don't know of any Core Audio
API that uses signals to do anything.
On Jan 23, 2007, at 1:59 PM, Corey O'Connor wrote:
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.c
How 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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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