• 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: AudioConverter "insz" error related to sample rate?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AudioConverter "insz" error related to sample rate?


  • Subject: Re: AudioConverter "insz" error related to sample rate?
  • From: Christopher Ashworth <email@hidden>
  • Date: Fri, 5 Nov 2004 20:53:24 -0500

Thanks Mike,

And let me take a moment to humbly add myself to the (no doubt long) list of people who are very grateful for the MTCoreAudio framework.

For the record, my original mistake was a rookie problem, in that I assumed that AudioConverterFillComplexBuffer would request the full number of packets from its IO Proc all in one go. This would happen sometimes, but of course not all the time. Using Doug's tip I was able to realize my error.

However, once I got this working, I found yet another bug which was confounding me. Somewhat amazingly, your email below is the solution to that bug.

So kudos on your prescience.  :)

Best,
Christopher

On Nov 5, 2004, at 7:42 PM, Michael Thornburgh wrote:


AudioConverterFillComplexBuffer() can/will change the value of an ABL's audio buffers' mDataByteSize fields to reflect the number of frames actually converted. if you don't change it back before your next call to AudioConverterFillComplexBuffer(), then the mDataByteSizes may not match up with the frames you've asked to read out.


in the version of MTCoreAudio i haven't released yet (haven't had the time lately :( ) i have a new ABL utility function to clean up after AudioConverterFillComplexBuffer(), MTAudioBufferListSetFrameCount(). it just jams all the mDataByteSizes in an ABL to what they should be for that many frames of the number of channels in each stream. obviously, it doesn't have any way to verify (or determine on its own) how big it _should_ be, since you can't ask a malloc()ed memory block how big it's supposed to be.

anyway, this function is included below from my development version of MTCoreAudio. it will be in the next release, whenever that happens, so be mindful that if you upgrade my framework in the future, you'll need to remove this duplicate from your code (or just call it something different now :).

void MTAudioBufferListSetFrameCount ( AudioBufferList * buf, unsigned count )
{
unsigned buffer;

for ( buffer = 0; buffer < buf->mNumberBuffers; buffer++ )
{
buf->mBuffers[buffer].mDataByteSize = sizeof(Float32) * count * buf->mBuffers[buffer].mNumberChannels;
}
}


i use it by remembering how many frames my AudioBufferList is _supposed_ to hold, and then just reset my ABL right after using AudioConverterFillComplexBuffer():

...
AudioConverterFillComplexBuffer ( converter, _FillComplexBufferProc, &callbackContext, &framesRead, outputBufferList, NULL );
MTAudioBufferListSetFrameCount ( outputBufferList, outputBufferListFrameCount ); // gross
...


hope this helps.

-mike


On Nov 5, 2004, at 9:09 AM, Doug Wyatt wrote:

On Nov 5, 2004, at 7:11, Christopher Ashworth wrote:
I am using an Audio Converter to help play files from disk to an output device. The converter is created using the stream description of the file as the input description and the stream description of an MTCoreAudioDevice as the output description.

When playing a file, I have the playback IO proc reading from an MTAudioBuffer, and a separate thread filling up that buffer. Inside the thread that fills the buffer, I read a certain number of packets from the audio file and convert them into an AudioBufferList by calling AudioConverterFillComplexBuffer. (Just for reference, the AudioBufferList is created via MTAudioBufferListNew). Then I write that AudioBufferList into the MTAudioBuffer.

This works perfectly as long as the sample rate of my input file matches the sample rate I am converting to. If the sample rate of the file is different, the AudioConverterFillComplexBuffer function returns an "insz" error.

I am sure there is enough room in the AudioBufferList to receive the converted data. Also, if I artificially set the output stream description to the same sample rate as the file when setting up the converter, it converts fine (although of course the sound I hear is either sped up or slowed down since the rate isn't correct for the output device).

An earlier version of this code (before I added the use of the buffers) converted the same files and played them back correctly. Is this maybe related to converting into an AudioBufferList created by MTAudioBufferListNew, rather than into the AudioBufferList I would write into before, which was provided by the playback IO function?

kAudioConverterErr_InvalidInputSize ('insz') is returned when the number of bytes (in the buffer list's buffers) and number of packets returned by the input proc are inconsistent.


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
References: 
 >AudioConverter "insz" error related to sample rate? (From: Christopher Ashworth <email@hidden>)
 >Re: AudioConverter "insz" error related to sample rate? (From: Doug Wyatt <email@hidden>)
 >Re: AudioConverter "insz" error related to sample rate? (From: Michael Thornburgh <email@hidden>)

  • Prev by Date: Re: AudioConverter "insz" error related to sample rate?
  • Next by Date: altivec problems
  • Previous by thread: Re: AudioConverter "insz" error related to sample rate?
  • Next by thread: Developing a CoreAudio driver validation tool?
  • Index(es):
    • Date
    • Thread