site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com ~ Josh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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 This email sent to site_archiver@lists.apple.com