Re: "Friendly" setting sample rates
Re: "Friendly" setting sample rates
- Subject: Re: "Friendly" setting sample rates
- From: Brian Willoughby <email@hidden>
- Date: Mon, 19 Oct 2009 18:22:53 -0700
On Oct 19, 2009, at 07:04, Stéphane Letz wrote:
We want our application be more "friendly" with others (..) when
sample rate changes are in concern. That is instead of "forcing"
the sample rate possibly disturbing other already running
applications that use another SR, we would like to check the device
SR before.
Most applications we checked have quite a "totalitarian" behavior,
that is they usually restore their own SR settings without doing
any checkup, this end in disturbing other running applications. Or
even completely "stupid" reaction like some applications that
receive the new SR notification but try to force back their own
chosen SR... (I'm thinking at GarageBand here...)
1) It seems that "kAudioDevicePropertyDeviceIsRunningSomewhere"
property is ready for that..., but it does not seem to work
correctly with "aggregate devices". That is checking an aggregate
device used by another application fails (but checking the sub-
device used in this aggregate device works..) Is it the expected
behavior? or a bug?
2) If the user plans to use an audio device that is already used by
another application, then we could checkup the currently used SR
(using the kAudioDevicePropertyDeviceIsRunningSomewhere property)
and *only display* this specific SR value. (We could also have
"force" mode when the user may change the SR possibly disturbing
others...). Dos this make sense?
Apple seems to recommend some basic strategy about SR management
but very few applications behave correctly. Maybe is is time to
agree on some common features?
In my experience, only one application forces the sample rate, and
that's Logic. But, for me, that is acceptable, because Logic is a
professional tool, and I expect it to take control of the interface.
I don't use GarageBand, so I never noticed that it does the same
thing. So far, nothing else that I use for audio will change the
sample rate, so I just prepare for the inevitable whenever I run
Logic, and make sure I'm not doing anything else with audio if I run
Logic. Usually, that's not a problem.
Ideally, I would suggest that if you want to set the sample rate (or
anything else), your application should attempt to "hog" the
interface, and only change settings if you succeed in gaining private
control of the interface. Otherwise, if the sample rate doesn't
match, and the interface is still being shared with other
applications, then perhaps your best choice is to generate a popup
message to alert the user. Then, the user can go into Audio MIDI
Setup and change the sample rate manually. If sample rate issues are
critical, then it should not be a big issue for the user to make the
settings, because they can take care of all the ramifications in
other applications at the same time. I don't know whether my
recommendations are kosher according to Apple's guidelines, but it
seems like a good way to cooperate.
If the above is not sufficient, then perhaps you could have a
Preference setting which is Off by default, but when manually turned
On by the user, it would allow your application to set the sample
rate. Basically, this would be a "Professional" versus "Consumer"
setting. Most consumers don't really care whether their audio runs
through SRC. They just want everything to run smoothly, and the last
thing they want is for one application to force settings which could
interfere with another. But professional audio users may be doing
mastering, or otherwise evaluating the finer details of the audio, in
which case they want the interface running at the precise sample rate
of the audio data, and they'd probably be willing to quit a few other
applications to make this happen. Whether your application automates
this by forcing the sample rate, or popping up a warning asking the
user to manually change the sample rate, it seems like either one
would be a reasonable choice for a detail-oriented user to deal with.
In my opinion, I would recommend against programmatically changing
the sample rate. It seems like the last thing we need is one more
application that forces a change, potentially causing trouble.
Brian Willoughby
Sound Consulting
_______________________________________________
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