Re: CoreAudio driver's convertInputSamples()
Re: CoreAudio driver's convertInputSamples()
- Subject: Re: CoreAudio driver's convertInputSamples()
- From: Doug Wyatt <email@hidden>
- Date: Tue, 22 Mar 2005 12:55:45 -0800
On Mar 22, 2005, at 12:25, Tommy Schell wrote:
Thanks for the reply.
I manipulated my 24 bit audio data to be high byte aligned in each
32 bit chunk, but I still am getting no audio coming through
using the conversion routines mentioned before.
I tried specifying the bit depth as 24 and 32 as the last arg to
these functions, but to no avail.
Once your data is high-aligned, then you would specify 32 bits as the
bit depth, since you've effectively got 32-bit data with the low 8
bits all zeroes.
Then I tried the un-optimized sample code from PhantomAudioDriver's
convertInputSamples(), and this produced
some partially recognizable legitimate sound coming through when I
tried with Final Cut, and the audio bars were
moving around more or less appropriately.
Are there any other alternatives for converting from 24 bit to 32
bit floating point?
I would start with the brain-dead simplest possible conversion code
to start with, and test it in isolation to make sure it is converting
properly. Sample code is just a starting point; ultimately you'll be
responsible for all the code in your driver so you might as well
start here.
Then if you're still having problems getting correct samples into an
app, then you'll know the problem isn't in the conversion routines.
You might find that your driver's time stamps are off, for example.
I'm thinking that because the sound is only partially recognizable
when using the unoptimized sample code, there is something else going
on. I haven't looked at the unoptimized code so I can't comment on
its correctness.
Once you get things working, then you can pay attention about the
efficiency of the conversion routines. (Please do; unoptimized int-
>float conversions can be especially expensive on G5.)
(I'm not exactly clear where I should do the bit shifting suggested
in the previous email: within the conversion routine?)
Yes.
Doug
Thanks,
Tommy
On Mar 21, 2005, at 10:21 AM, Doug Wyatt wrote:
On Mar 21, 2005, at 8:13, Tommy Schell wrote:
Hi,
I have a question about implementing convertInputSamples() in a
CoreAudio driver.
I was running Hacktv with my driver selected for audio and my
device providing 24 bit, signed, low byte aligned audio data,
and the sound produced was a constant fuzzy sound.
I realized that in my convertInputSamples routine, I was
converting from 16 bit to 32 bit float, instead of 24 to 32.
So I tried using some of the 24 bit to 32 bit float conversion
routines from PhantomAudioDriver:
NativeInt32ToFloat32
SwapInt32ToFloat32,
and then specifying the depth as 24.
These attempts produced no sound whatsoever! And I know that
convertInputSamples is being called as it should be.
Any ideas?
I haven't tested them lately, but I suspect that those routines,
despite their intentions, aren't correct for low-aligned cases
like this (any time mBitsPerSample != mBytesPerFrame * 8). It
looks like the code is assuming that the high 8 bits are sign-
extended from the (1 << 23) bit in the case of 24 bit samples. To
fix this, you could add two instructions per sample, to shift the
ints 8 bits left and then 8 bits right before storing them into
the int->float memory buffer.
You could advance your pointer into the source samples by one byte
and add a trailing 0 byte, then have it treat the samples as
signed 32-bit ints, but then you'd be loading from unaligned
addresses.
Doug
_______________________________________________
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