Re: Proper API for selecting devices
Re: Proper API for selecting devices
- Subject: Re: Proper API for selecting devices
- From: Jeff Moore <email@hidden>
- Date: Fri, 3 Dec 2004 11:35:05 -0800
Good to see you've narrowed down the problem you were having.
To answer your other question, applications, in general, don't need to
muss around with the device settings. They should just adapt themselves
to the environment the user has configured with AMS and refer the user
to AMS when things when settings need to change.
I say in general because this isn't a hard and fast rule. An app that
is doing recording or live monitoring or what have you would be a good
candidate to include some UI to allow the user to adjust input gain or
the input data source of a device or stream. It comes down to making
life easier for your users while recognizing that changes to the
hardware can and will affect the other apps that are running.
That said, it should never be the case that an app assumes it has full
control over a given device (except if the app hogs the device of
course). Apps should always react in a reasonable way when the settings
change on an audio device they are using. Apps need to be good citizens
in this area and sign up for all the notifications the HAL delivers and
do the right thing in response or, better still, let AUHAL do all that
work for you.
On Dec 3, 2004, at 2:31 AM, Roni Music wrote:
The data source controls, like all controls, can be manipulated
regardless of whether the device is performing IO or not. Try it
yourself in AMS or HALLab to see.
Without seeing a backtrace of your crash, it's hard to say what would
be causing it exactly. But if I had to guess, I'd say that it's
happening because DataSourceControlIsSettable() is throwing an
exception that you aren't catching.
No I'm catching those
The reason an exception would get
thrown is because the device probably doesn't have a data source
selector control at the address you are querying. You should always
check for the existence of the control using HasDataSourceControl().
Doing that as well
Now it actually seems that the tests I did with the CompleThru example
works fine,
both with DigiDesign and other hardware (despite what I previously
said). The problem
seems to be when I move the code over to my own application. ;-)
Should be possible to fix
Now, in another response to a question of mine someone said:
"...., it is often better to let the user configure the Built-in audio
device using the System
Preferences Sound Panel, and select among the inputs (data sources)
there."
Is selecting the data source from within an application not a good
idea?
It seems it may change a system wide setting?
Thanks for responding
Rolf
On Dec 2, 2004, at 6:22 AM, Rolf Nilsson wrote:
Hi,
Some more questions about kAudioDevicePropertyDataSource:
From: Jeff Moore <email@hidden>
Subject: Re: Proper API for selecting devices
Here's what I wrote the last time. It still answers the question.
The HAL provides the list of available devices through the
kAudioHardwarePropertyDevices property. Then for each device, you
can
query the kAudioDevicePropertyDataSource family of properties to
access the input source (e.g. line in or internal mic on my PB).
Should this be done before one is actually starting using the device?
CAAudioHardwareDevice theDevice(theInputDeviceID);
if (theDevice.DataSourceControlIsSettable(kAudioDeviceSectionInput))
theDevice.SetCurrentDataSourceByID(kAudioDeviceSectionInput,
theInputDataSourceID);
i.e. before the SetupAUHAL() etc as in the ComplexThru example?
I've tried both and it seems to work on a PowerBook for selecting
between the Mic and Line-in
but the same thing crashes when a user tries it with a Digidesign
ProTools interface.
Is there anything special with Digidesign or am I doing it wrong?
I've uploaded a modified version of the ComplexThru example here:
http://www.ronimusic.com/download/CmplxPlayThru.sit
In the original example there are popup menus for selecting the
device,
I've just added a couple of popup menus for selecting the data source
as well a combined menu for the
available devices/sources.
It contains the test application and also the source code as an XCode
project (it should build right out of the box )
Thankful for any comments what might be wrong?
Rolf Nilsson
--
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