Re: "Friendly" setting sample rates
Re: "Friendly" setting sample rates
- Subject: Re: "Friendly" setting sample rates
- From: Jeff Moore <email@hidden>
- Date: Wed, 21 Oct 2009 13:09:33 -0700
On Oct 19, 2009, at 7:04 AM, 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.
For the vast majority of applications, the rule of thumb with regard
to the various device settings is to accept them as they are and to co-
exist peacefully without changing anything. In fact, this is the rule
we've been living by since before MacOS X even and is in fact the rule
that governs iTunes, QuickTime, etc.
BTW, this does mean accepting that there may be a need to do rate
conversion.
Most applications we checked have quite a "totalitarian" behavior,
that is they usually restore their own SR settings without doing any
checkup,
There are exceptions to the rule. Apps for making music are often in
this category, pro or otherwise.
this end in disturbing other running applications.
Indeed. But since this is initiated directly by a user action like
launching a heavy weight app like GarageBand or Logic or Live or Pro
Tools or what have you, the effect is mitigated.
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...)
Cross-process property setting wars are bad. They can lead to DOS
attacks and lots of other bad behavior. I encourage you to file bugs
against apps that engage in practices like this.
IMHO, the right thing for an app that is particular about the value of
a property on an audio device is to set it once and then degrade
gracefully if the setting changes later. If the app absolutely cannot
continue without the proper value, it should interact with the user
when the value changes externally so as to prevent the death spiral of
constantly setting the property. It should never just blindly reset
the property to the "right" value.
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?
Aggregate devices are process local, so
kAudioDevicePropertyDeviceIsRunningSomewhere is a synonym for
kAudioDevicePropertyDeviceIsRunning. Note that this is also true of
many devices that are implemented with a user-land driver.
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?
The problem with this is that for a lot of apps, whether the device is
running or not makes little difference to whether or not the app
itself is prepared to have the sample rate change out from under it.
In other words, preventing the sample rate from changing when the
device is running does not solve the problem if the app itself doesn't
want the sample rate to change at all.
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?
I would argue that the strategy is already there and that apps that
misbehave need to have bugs written about the problems.
--
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