I spent too much time figuring out how to get the VPIO unit to work on OSX and also on iOS. I don't remember much off the top of my head since it's been almost a year since I touched either one. Here are some things I do remember:
* VPIO is not always a drop-in replacement for HAL - there are some differences. * There are some differences between VPIO on iOS and on OS X. * There is a setting on VPIO (don't recall which one) whose sense is backwards - true to turn off the feature. * Apple documentation refers to "voice processing" - that's echo cancellation and probably some noise cleanup too. * It was critical to look in Apple's documentation, the comments in the .h files, and example programs. Each place revealed important information absent from the other two. VPIO is an awesome unit that hides some fairly serious complexity. It's well worth the trouble to get it to work! It copes with input and output devices that can be running at different sample rates and formats in a way that seems to imply it has its own thread and buffers, yet it adds no latency as far as I could tell. Your inputUnit_ and outputUnit_ both will be replaced by a single VPIO unit. Your application structure sounds like a simple test program to read from the microphone and play it out the speaker. I wrote a test program that did that. (I tried having the Render callback turn around and call the function that obtains data from the microphone side of the VPIO, and that didn't work - I would guess the VPIO has internal locks around data structures that prevents that. Then I tried setting up a single static buffer to hold samples: the input callback fills the buffer and the render callback plays it out. This worked fine -- as long as the input and output buffer sizes and formats were the same. I don't remember which is called first, the render callback or the input callback. But they are called one after the other, like clockwork. As you'd expect. The circular buffer is important for most real applications; I don't recall why I wanted to avoid it in my test program.) If you want, I can try to dig up the test program and send it to you. Let me know directly; no need to clutter the list. Steven J. Clark [email protected] VGo Communications -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Éloi Bail Sent: Tuesday, April 14, 2015 11:39 AM To: [email protected] Subject: Enabling echo canceller on macosx Hi, I am working on an open source VOIP project. On MacOSX (tested with version 10.10 - Yosemite), we had an echo. So we wanted to add system echo canceller. kAudioUnitSubType_VoiceProcessingIO seems to be the appropriate solution. Our audio architecture (without echo canceller) is quite simple : - 1 ringbuffer : a circular buffer where audio samples are stored and loaded - 1 audio unit to capture micro (inputUnit_) * inputUnit_ is a subtype kAudioUnitSubType_HALOutput * inputUnit_ has a inputCallback that write audio samples from microphone to our ring buffer - 1 audio unit to output audio (outputUnit_) * outputUnit_ is a subtype kAudioUnitSubType_DefaultOutput * outputUnit_ has a RenderCallback that read audio samples from ring buffer and output them on speakers This system works fine, but as I said, we have an echo. The full GPL code is available there : http://pastebin.com/pth0f8wt I tried then to switch outputUnit_ from kAudioUnitSubType_DefaultOutput to kAudioUnitSubType_VoiceProcessingIO. I also ensure to disable output muting. The full GPL code is available there : http://pastebin.com/kAwL8fax With kAudioUnitSubType_VoiceProcessingIO, I still have an echo. Could you tell me what I am doing wrong ? Could we use kAudioUnitSubType_VoiceProcessingIO with my architecture ? Shall we use more complicated pattern such as AUgraph ? Thanks, Eloi _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/steven.clark%40vgocom.com This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
