Re: Changing nominalSampleRate considered harmful?
Re: Changing nominalSampleRate considered harmful?
- Subject: Re: Changing nominalSampleRate considered harmful?
- From: Mike Kluev <email@hidden>
- Date: Mon, 21 Jul 2008 12:49:23 -0800
Jeff,
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 :)
> 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.
> 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...
> 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?
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?).
Mike
_______________________________________________
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