Re: kAudioDevicePropertyStreamFormatMatch rate is zero in Panther
Re: kAudioDevicePropertyStreamFormatMatch rate is zero in Panther
- Subject: Re: kAudioDevicePropertyStreamFormatMatch rate is zero in Panther
- From: Jeff Moore <email@hidden>
- Date: Thu, 20 Nov 2003 16:04:04 -0800
On Nov 20, 2003, at 1:49 PM, Phil Burk wrote:
Hello Bill,
Basically the problem is that some folks are reporting that some
PortAudio
apps that worked under Jaguar now fail under Panther. They seem to be
apps
that try to lower the sample rate to 8000.0 Hz and are using USB audio
devices.
PortAudio uses kAudioDevicePropertyStreamFormatMatch to find the
nearest
match to their desired rate, which made me think it may be associated
with
the report from here:
http://lists.apple.com/archives/coreaudio-api/2003/Jul/18/
halpatherformatmatchingb.001.txt
As I said in my off-list response, this bug was fixed during the
development of Panther using code that won't ever return 0 for the
sample rate. It actually checks to see if it is about to return 0 and
if it is, will replace the 0 with either the sample rate requested or
the current sample rate (which is never 0).
The only way you could get the result you are reporting is if the call
to AudioDeviceGetProperty() was returning an error. In this case, the
HAL 0's out the whole data structure.
We have found that if we hack PortAudio to not change the sample rate,
and
just use an AudioConverter to change the rate in software, then the
apps
will work.
Maybe you should start at the beginning and describe the symptoms of
the problem before we go down the alley of assuming that
kAudioDevicePropertyStreamFormatMatch is causing the trouble. It could
be that the problem is happening somewhere else along the path used to
change the sample rate.
I do not have Panther so I am waiting for some more reports from users
who
are running tests.
Installing QuickTime 6.4 on top of Jaguar will get you the same version
of the HAL that is in Panther. So this is a great way for you to test
it yourself and really look at the situation in gdb.
I am thinking that it may be preferable to never change the HW sample
rate
anyway and just use SW rate conversion. Given that changing the HW
sample
rate affects other apps, it seems a bit rude. Maybe we should only
change
the rate if someone requests a rate higher than the current rate, like
96
KHz.
In general, I would say that applications should not be changing the
format of the hardware, unless they really really really need a
specific setting, e.g. to do AC-3 output. Instead, the user should be
in charge of the hardware settings and they use Audio MIDI Setup to
configure the hardware the way they want it. Apps should honor this
selection and should not arbitrarily change it. Further, if they do
change the format, they should be polite enough to change it back to
whatever it was before they changed it.
But at this point I am more worried by the apparent change in behavior
between Jaguar and Panther. Are we seeing a bug that was fixed, or
introduced, or a new feature?
By the way, the latest PortAudio code is available here:
http://www.portaudio.com/
If someone wants to experiment with this they could try changing the
sample
rate in patest_record.c to 8000 Hz and try it with a USB serial
device, like
an iMic. I'm not certain that it will reproduce the effect but it is
likely
to.
I'd like to know what the problem is before we try to guess what's
causing it. All I've heard so far is speculation that
kAudioDevicePropertyStreamFormatMatch isn't working, of which I am very
skeptical given the experiments I've been doing.
Feel free to follow up off list if you'd like.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.