Re: implementing an AudioIOFunction
Re: implementing an AudioIOFunction
- Subject: Re: implementing an AudioIOFunction
- From: Josh Rodatus <email@hidden>
- Date: Tue, 26 Dec 2006 11:18:15 -0500
The problem is that you are introducing latency into the process,
probably because you are serialising the audio output behind some or
all of your display code.
To be honest I don't exactly know what you mean by serializing audio
output behind the display code, but besides the socket communication
I'm definitely not copying blocks of samples during the processing.
Even so, the computer's audio stream isn't dependent upon the speed of
the process that does the processing/displaying in any way (that I know
of).
It sounds like what you want is a tap on the output, not to actually
be blocking the output path. Also, you definitely don't want to be
doing any real work on the output thread.
Without changing your model too much, the best suggestion I have is
for you to implement a lossy buffer (a ring of some sort) in memory
supplied via a userclient, and just copy into that ring while you're
copying from input to output. I still don't think that's as good as a
straight tap would be, but I'm afraid I don't know enough about the
audio stack to know how you'd go about getting there.
Thank you for that suggestion. Would I use an IOMemoryDescriptor to
share that user-space ring buffer? I must admit I'm new to kernel
programming.
When you say "straight tap", do you mean like asynchronously calling
IOAudioEngine::getCurrentSampleFrame()? That may introduce some new
complications, but is an interesting idea.
~ Josh
On Dec 26, 2006, at 4:23 AM, Michael Smith wrote:
The problem is that you are introducing latency into the process,
probably because you are serialising the audio output behind some or
all of your display code.
It sounds like what you want is a tap on the output, not to actually
be blocking the output path. Also, you definitely don't want to be
doing any real work on the output thread.
Without changing your model too much, the best suggestion I have is
for you to implement a lossy buffer (a ring of some sort) in memory
supplied via a userclient, and just copy into that ring while you're
copying from input to output. I still don't think that's as good as a
straight tap would be, but I'm afraid I don't know enough about the
audio stack to know how you'd go about getting there.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden