• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Getting Levels While Recording
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting Levels While Recording


  • Subject: Re: Getting Levels While Recording
  • From: Matt Connolly <email@hidden>
  • Date: Fri, 18 Aug 2006 06:59:44 +1000

Hi Dan,

I had a similar problem. It seems that there is no need to Endian swap float32's, but unless you specify by hand that you don't need to, CoreAudio will swap them and your numbers turn into meaningless NaN and Inf, etc....

In the header file "CoreAudioTypes.h", below the normal Audio Format Flags, is this one:

kAudioFormatFlagsNativeFloatPacked

That might be useful to tell coreAudio that the Float32's do not need to be endian swapped.


Also, I have a C++ class which easily measures both Peak and RMS levels, with the appropriate IEC/ISO attack and release time ballistics. Quite simple code, but you are welcome to use it if you are interested. The attack and release ballistics are implemented using first order butterworth filters, which are implemented based on some maths I read in a book that was written before I was born.


All the best,
Matt Connolly


Hi,

I'm trying to get levels while recording an audio sample - or rather I'm trying to make it work on an intel machine based on existing code that works on PPC.

The current code looks like this:

Float32 *samples = (Float32 *)buffer->mData;
Float32 *limit = (Float32*) (((UInt8*)samples) + buffer- >mDataByteSize);


where buffer is of type AudioBuffer *

This is then passed to the function:

static void computeMaxLevels ( float* samples, Float32* limit, Float32 levels[2] )
{
Float32 leftMin, leftMax, rightMin, rightMax;
leftMax = leftMin = rightMax = rightMin = 0.0;


// compute the maximum level in each channel (hardcoded Float32 samples, 2 interleaved channels).
while ( samples < limit )
{
Float32 left = samples[0];
if (left > leftMax)
leftMax = left;
else if (left < leftMin)
leftMin = left;
Float32 right = samples[1];
if (right > rightMax)
rightMax = right;
else if (right < rightMin)
rightMin = right;
samples += 2;
}
levels[0] = max ( leftMax, abs(leftMin) );
levels[1] = max ( rightMax, abs(rightMin) );


	levels[0] = 20.0 * log10(levels[0] * levels[0]);
	levels[1] = 20.0 * log10(levels[1] * levels[1]);
}

PPC - the levels come out fine, but on intel they are way out of whack, making me think I'm dealing with a different data format on that platform.

I've been looking through all the docs I can find to see what the data in buffer->mData looks like, but I am really out of my depth with this coreAudio stuff. If anyone can offer a helping hand, I would greatly appreciate it, even if it's to tell me that I'm looking in the wrong place to fix this problem.

Thanks,
Dan

_______________________________________________ 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
  • Prev by Date: Wave data and CoreAudio
  • Next by Date: PCMBlitterLibPPC - for Intel
  • Previous by thread: Re: Getting Levels While Recording
  • Next by thread: Re: Getting Levels While Recording
  • Index(es):
    • Date
    • Thread