Re: Device input format change.
Re: Device input format change.
- Subject: Re: Device input format change.
- From: Tommy Braas <email@hidden>
- Date: Fri, 2 Feb 2007 11:43:36 +1100
On Feb 2, 2007, at 8:57 , Jeff Moore wrote:
On Feb 1, 2007, at 1:39 PM, Tommy Braas wrote:
Thanks for your speedy response Jeff.
We allow our users to modify the device settings, as they expect
to have full access to all formats provided by a device from
inside our recording application. We'd like to be able to modify
device settings as robustly as it is done in AMS, which we
currently apparently are not doing.
Why not just bring AMS to the front and let the user do it there?
Product management would not approve that. But if the AMS would lend
itself to be embedded as a component, then we'd be talking.
After changing the property on the AudioDevice, we do indeed wait
for the callback to occur before we proceed to start the device.
All we do in the IO proc is pushing the received audio samples to
an AudioFile via an AudioConverter.
When you get the notification, are you checking the format again,
or just assuming that what you set with the SetPropertyData call is
what the device is using?
We update the UI with the current settings of the device, but we
don't compare the format we tried to set on the device with the
actual one it has after the callback.
We are not currently using AudioUnits. Would using the
HALOutputUnit for input, in your opinion, help resolve this issue?
Using AUHAL to do the heavy lifting of being a proper HAL client is
always a recommended approach. It deals with many of these sorts of
issues precisely so that you don't have to.
I suspected you would say that.
So in essence, the recommended solution would be:
1. Change physical stream format on AudioDevice
2. Create AUHAL for AudioDevice
3. Record
Yes?
Regards,
\tommy
Kind regards,
\tommy
On Feb 2, 2007, at 6:18 , Jeff Moore wrote:
First off, the general rule of thumb is that applications should
not be fiddling with device settings. Settings belong to the user
and should be set using the system apps. Obviously there are
exceptions to every rule, but most apps should respect the
settings the user has already made.
That said, the problem here is probably due to your app not using
the correct format in your IOProc. The usual mistake that gets
made here is assuming that the format you set is the format the
device actually is using. The other common mistake is assuming
that the format change takes place immediately, when in fact
changing the format is an asynchronous operation that can't be
deemed complete until your listener proc gets called indicating
that the format did, in fact, change.
On Feb 1, 2007, at 11:05 AM, Tommy Braas wrote:
I am currently facing a problem when changing the input stream
format on a recording device using HAL.
When it is done in my application, the device ends up generating
pink noise. When the device is set as the default system input
device and the input stream format changed using AMS, there is
no pink noise!
Can anyone speak to what the issue might be here, or at least
describe the recommended sequence of input stream property
changes in HAL?
--
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:
40deepseasoftware.com
This email sent to email@hidden
--
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:
40deepseasoftware.com
This email sent to email@hidden
_______________________________________________
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