Re: More info: SoundConverterConvertBuffer() is broken on Mac OS X
Re: More info: SoundConverterConvertBuffer() is broken on Mac OS X
- Subject: Re: More info: SoundConverterConvertBuffer() is broken on Mac OS X
- From: Andrew Taylor <email@hidden>
- Date: Thu, 13 Dec 2001 14:28:22 -0500
At 3:50 PM -0800 12/12/01, Jeff Moore wrote:
on 12/12/01 2:38 PM, Andrew Taylor <email@hidden> wrote:
> For Mac OS X, interrupt callbacks don't seem to work.
Unfortunately, there is a bug in the sinp component that sits on top of the
HAL that prevents this from working.
> So I rewrote
> the code to use a completion routine, which works, but the resulting
> data coming out of SoundConverterConvertBuffer is wrong. It is as if
> the voice played back is very very very slow.
>
> Has anybody else encountered this?
> Has something changed in the data that is delivered from SPBRecord?
> Are different parameters required for SoundConverterConvertBuffer() ?
The components the SoundConverter uses are pretty much the same code on X as
they are on 9. This behavior has not come up in any testing. Can you distill
the code down and provide an example?
Your answer below sparked a memory and I just confirmed it. I had
not thought to verify the difference before.
The default compression on Mac OS 9 is 'NONE'. At least that is what
I see when I ask the input device.
The default compression on Mac OS X is 'twos'.
As part of the initialization process we set the compression to
'NONE', but then our subsequent check of that setting shows it to be
'twos' anyway (on Mac OS X). There is no error reported when setting
compression to 'NONE'.
In addition the number of channels stays at two in Mac OS X (no
error reported) and Mac OS 9 succeeds when we set the number of
channels to 1.
So:
compression - X -'twos' vs 9 - 'NONE'
num channels - X - 2 vs 9 - 1
I imagine that this affects the data that is delivered in the sound
buffers and therefore why SoundConverterConvertBuffer does not work
as expected.
Now what can I do about it?
Thanks.
An error in the above report: trying to change the number of channels
to 1 does cause an error of -201.
It does appear that SoundConverterConvertBuffer will take arguments
that provide for reduction of the number of channels in the sound
data (at least no error is reported).
However at this point my assumptions and calculations of the data
that I am processing are probably all wrong since the input data is
twice what I was expecting.
So it might be a while before I can confirm that
SoundConverterConvertBuffer does number of channels reduction as well
as frequency reduction.
--
---------------------------
Andrew Taylor
Founder/CTO
MacSpeech, Inc.
<
http://www.macspeech.com>