Re: Quality of CoreAudio SRC
Re: Quality of CoreAudio SRC
- Subject: Re: Quality of CoreAudio SRC
- From: Paul Fredlein <email@hidden>
- Date: Fri, 1 Feb 2008 22:38:17 +1000
Hi,
My app is designed for foreign language learning at high school. As
most schools prefer to run the software from the CD rather than
installing it on the hard disk I read all the audio, including that
recorded by the student, for each 'page' into RAM (- cause the CD
spins down) .
As it is speech there is no point in the audio being 44100 @ 24bit so
22050 @ 16bit is fine but if the hardware defaults to a high quality,
such as 'Builtin audio' then I'm filling up buffers unnecessarily. I
would much prefer to set the hardware to what I want at runtime, as I
do on Windows - and return it to was it was, but it seems that this is
undesirable on OSX - any suggestions? Teachers don't want students
wasting class time fiddling with audio settings.
I suppose for each page there would be a max of 20meg of audio in RAM
- I know it's not much today, it was 10 years ago, but it just seems
a waste of resources.
Thanks,
Paul
On 01/02/2008, at 9:01 AM, Jeff Moore wrote:
Basically, what Stephen is saying is something we've been saying
since Day 0 of Core Audio and OS X. The hardware settings belong to
the user. They should not be changed by applications. Rather,
applications should be adapting to the settings of the hardware
including responding to dynamic state changes.
The basic reason why is that the audio system on OS X is designed to
be shared amongst all applications on the system. No application
knows enough to say with any certainty what is going in other
applications. Doing something like changing the sample rate can have
serious consequences to other applications on the system ranging
from causing a glitch in playback/capture or outright failure of
some process due to the interruption or temporary loss of synch. In
a badly coded application, it can cause a crash (see the recent
thread about the bug in HALLab for an example). In fact, I could go
on about the bad things that can happen to other applications when
one app thinks it owns the hardware and makes unwarranted changes to
settings.
On Jan 31, 2008, at 2:30 PM, Mikael Hakman wrote:
On January 31, 2008 Stephen Davis wrote:
IMHO, it is bad form to be changing the audio hardware's sample rate
for each track. If you're gunning for the absolute highest quality
output then maybe it's okay but it's pretty obnoxious to the rest of
the system and should be clearly communicated to the user.
Would you or other knowledgeable member on this thread kindly
explain why rate-following would be bad, in absence of other rate-
locking signals such as digital input or word clock etc., please?
Why couldn't e.g. iTunes send the actual sample rate information
down the chain of software layers until it arrives to the hardware
(DAC)? The sample rate would need to be changed only when the rate
used by the actual track is different from previous. I have been
discussing this with few audio interface vendors. While they agree
that not doing SRC would be the best, they blame on application and
operating system vendors for not providing sample rate information
to their drivers/hardware.
For a user it is difficult if not impossible to keep track of what
sample rate a selected media is in, then use a control panel or
Preferences or both to change the rate, and first then to play the
track. Many users want to simply select a track, perhaps in Front
Row using a remote control from the couch, and play it, or even
play a number of randomly selected tracks. Why can't we give even
these users the best audio quality available on the system?
--
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
_______________________________________________
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