Re: Switching Device Programmatically and Subsequent call to AudioDeviceGetCurrentTime
Re: Switching Device Programmatically and Subsequent call to AudioDeviceGetCurrentTime
- Subject: Re: Switching Device Programmatically and Subsequent call to AudioDeviceGetCurrentTime
- From: Recy Pilloud <email@hidden>
- Date: Tue, 2 Dec 2008 11:58:40 -0700
If it is a bug in CAPlayThrough, do you have any suggestions for how we could work around it on Tiger? It almost seems like a timing issue on Tiger (i.e. the call is made to change the device, the previously selected device gets stopped, but doesn't get restarted before the call to AudioDeviceGetCurrentTime).
Recy
On Dec 1, 2008, at 4:45 PM, Jeff Moore wrote:
This doesn't sound to me like a systemic issue. Rather, it sounds more like a bug/behavior in CAPlayThrough. Being sample code, it isn't a thoroughly polished application. I'm sure that there are a few edge cases it doesn't handle as well as it could. So you could easily be running into such an issue.
On Dec 1, 2008, at 4:33 PM, Recy Pilloud wrote:
We have an application where we are capturing system output with our proprietary device, processing it, then sending it to a system output device (built-in, headphones, USB, etc.).
When our application initializes, we programmatically switch the default output device to our device (so all system output gets directed to our device) with the following call:
err = AudioHardwareSetProperty(kAudioHardwarePropertyDefaultOutputDevice, sizeof(Uint32), &inputDevice);
We are using CAPlayThrough to stream the data from our device (the input) to the system output device (the output).
After we programmatically switch the default output device, the system appears to stop the device that was previously selected (e.g. built-in speakers, which is the device we send output to). This causes subsequent calls in CAPlaythrough to AudioDeviceGetCurrentTime to get the time from the system output device to fail.
If we change system output device (e.g. plug or unplug headphones), the problem corrects itself.
We are only seeing this problem on the Tiger OS (10.4.11). We do not see the problem at all on Leopard.
We have verified the problem occurs in the CAPlayThrough example code on Tiger as well by adding the call to programmatically switch the device in the CAPlayThroughController's awakeFromNib method.
Is there something different we should be doing on Tiger systems to avoid this problem? Is this a bug in CoreAudio?
--
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