Re: implementing an AudioIOFunction
Re: implementing an AudioIOFunction
- Subject: Re: implementing an AudioIOFunction
- From: Josh Rodatus <email@hidden>
- Date: Tue, 26 Dec 2006 15:17:23 -0500
Thank you all for your help. I think you've got me on the right track
now.
~ Josh
On Dec 26, 2006, at 3:09 PM, Kevin Elliott wrote:
At 11:18 -0500 on 12/26/06, Josh Rodatus wrote:
How often are you writing to the socket and ow much data are you
writing? My first guess would be that your writing so often that
the constants calls out to the driver is causing the system to
stutter.
I'm writing 2048 bytes of data every time the audio stream calls my
AudioIOFunction >function, about every 1/100 of a second.
My gut reaction is that that sounds like an awful lot of bouncing back
and forth between the kernel and user space. One simple thing to try
would be reducing the frequency of your writes- queue the data up and
do larger writes.
Someone suggested a shared ring buffer, and I can see some very
attractive advantages in that. It sounds like your just doing
display, which means you don't _really_ care how accurate the data in
the buffer is. If latency is becoming an issue, your much rather lose
data and hope to sync up in the future rather than try to stay to
synchronized. It sounds like you could basically get away with almost
no "communication" between kernel and user space. Basically your app
hands the kernel a memory buffer, the kernel writes data into it, and
your app reads data out of it. If the kernel gets ahead of you, you
lose data in the buffer- but you didn't want that data anyway, since
it's old data. Just to share credit, this technique is similar to how
isochronous transfers are handled by FireWire.
--
______________________________________________________
Arguing with an engineer is like wrestling with a pig in mud.
After a while, you realize the pig is enjoying it.
______________________________________________________
Kevin Elliott <mailto:email@hidden>
AIM/iChatAV: email@hidden (video chat available)
______________________________________________________
_______________________________________________
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