Re: Changing nominalSampleRate considered harmful?
Re: Changing nominalSampleRate considered harmful?
- Subject: Re: Changing nominalSampleRate considered harmful?
- From: Jeff Moore <email@hidden>
- Date: Mon, 21 Jul 2008 14:11:02 -0700
On Jul 21, 2008, at 1:49 PM, Mike Kluev wrote:
Thank you for your detailed answer,
On Mon, 21 Jul 2008 12:09:31 Jeff Moore wrote:
Correct. The sample rate setting belongs to the user. Applications
should not
be changing it. That's why iTunes and QT don't.
That's something new to me. It isn't mentioned in the documentation,
nor in the QA1196 but I can live with that (even without filing
radar :)
It's not exactly a secret. As someone else pointed out, this topic has
been discussed on this list quite a few times. Plus, this is the party
line we've been telling developers since Mac OS X made it's debut. Not
to mention we mention it during our WWDC presentations every chance we
get.
That's where /Applications/Utility/Audio MIDI Setup.app comes in
handy. Or are
you saying that's not good enough?
Yep, see my reply to Jeremy.
At any rate, a problem with this scenario is that if the user isn't
sophisticated enough to know what this whole "sample rate" thing
is, then
asking them to change it to 8K makes no sense. The first app in
this scenario
blew it right at the start by asking the user a question they can't
really
answer. If they are familiar with how the term is being used in
context,
generally they'll also understand how to change it themselves after
the fact.
Sounds reasonable. But, do you imply that monitor refresh rate
is less sophisticated concept than sound sample rate? :) Otherwise
I do not see why there is the one but not the other in the
standard preference panel.
One could argue that monitor refresh rate is probably out of place in
the prefs. That said, the video folks don't have the fall back of an
app like Audio MIDI Setup on the system.
This all just points out why it's always better for an app to leave
the
hardware the way the user has set it. The app should be the one
adapting to
the current settings. If your app works best at 8K, then you should
be
prepared to resample the data as necessary to make use of the
hardware the way
the user has set it up.
Thanks for mentioning this, I will.
Besides, 8K support in the hardware is becoming rarer
and the app may just be stuck with a non-optimal sample rate
because the
hardware does not support the rate the app desires at all.
About any USB headset I saw has 8kHz supported... But that's not
the point, I just picked 8 kHz as an example. Some people will
hear difference between 22kHz vs 44kHz vs 48kHz...
I think you are missing my point: an app is never guaranteed that they
will have optimal anything. They have to be prepared to make do in the
environment they find themselves. The sample rate is just one aspect
of this. This would include things like channel counts, sample
formats, hardware volume, etc. So by being adaptable, an app makes
itself much more friendly to the user and the rest of the system as
well as making itself able to work in a much wider variety of user
environments.
Also, any app that does need to change the sample rate or other
hardware
settings has to restore the hardware to the state the app found it
in when the
app is done using the hardware. An example of an app like this is
our DVD
Player. It needs to change the sample format to play AC-3 data. The
DVD Player
is also careful to save the hardware settings before changing them
so that
they can be restored when the DVD Player stops playing.
And if my app changes hardware settings "back", say on quit,
would it not introduce more harm to other programs that were
started after my app made initial hardware changes, "adapted"
to the these changes and continue to work after my app quitted /
restored hardware settings? Apps probably need to listen to
such changes, do they?
This is true. Apps always need to be prepared for things to change.
That's why there are so many notifications as well as why AUHAL is
such a good thing for developers (it does all that listening for you).
But, my point was more that apps should not be changing the settings
in the first place. I only included this information here because I
know that there are apps that really do need to change hardware
settings. That's why we provide public API for doing it. Generally,
these sorts of apps become the sole focus of the user running them
(e.g. the DVD Player or a pro app like Logic). So what happens to
other apps is much less of a concern than it would be under other
circumstances. Once the user changes focus, the well-behaved app will
change things back to what they were before.
Now I understand that doing sound output at AudioDeviceAddIOProc
level is too low level for me as it is affected by nominal rate
change. What API would you suggest to play sounds at arbitrary
frequencies? (in other words what level in CA closely resembles
the SndDoCommand + bufferCmd of SM?).
Sounds like you want <AudioToolbox/AudioQueue.h>.
--
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