• 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: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']


  • Subject: Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
  • From: "Edward Hervey" <email@hidden>
  • Date: Wed, 21 Mar 2007 08:17:55 +0100

Hi,

  Yes that behaviour control is already in it, else it would have
never worked with mp3 in the first place. If I don't return the ASPD
for mp3, it will work with both my code and the PlayAudioFileLite, but
if I return it it will fail with my code.
  The 100% cpu is after the very first call where I DO return some
information. my input proc only gets called once and I'm returning
exactly the same information as in the PlayAudioFileLite example.

     Edward

On 3/20/07, William Stewart <email@hidden> wrote:
Check if your input proc is being called repeatedly - if you have no
more input data, then you need to return an error from your input
proc; that is a signal that says "i have no input data now, stop
bugging me" - the converter will return that error code to you (as
the caller of the FillComplexBuffer call) and will try to give you as
much data as it can - probably not as much as you asked for - because
you didn't give it enough input

HTH

Bill

On 20/03/2007, at 10:36 AM, Edward Hervey wrote:

> Hi William,
>
>  I've been using the PlayAudioFileLite example from the ADC to figure
> out what those values were. From what I could observe when running it
> over several files, for both mp3 and AAC the values would be:
>    aspd.mStartOffset = 0;
>    aspd.mVariableFramesInPacket = 0;
>    aspd.mDataByteSize = len;
>  len being the size of the buffer returned in the buffer list.
>
>  When I modified that example to return that
> AudioStreamPacketDescription it works fine(in fact, it seems to play
> more files than before, IT had the '!pkd' error :) ). So thanks for
> that trick, it does indeed solve the problem regarding the '!pkd'
> error.
>
>   But when I modify my code to behave exactly the same way... it
> takes 100% cpu after calling the inputproc callback for the first
> time, without returning to AudioConverterFillComplexBuffer().
>
>  Using gdb I get these different backtraces when it's at 100% cpu
> (I'm not putting more, you can see it's all happening within
> CodecConverter::DecoderFillBuffer):
> #0  0x9427fa18 in AudioCodecProduceOutputPackets ()
> No symbol table info available.
> #1  0x029101b0 in CodecConverter::DecoderFillBuffer ()
> No symbol table info available.
> #2  0x028f3a5c in AudioConverterChain::RenderOutput ()
> No symbol table info available.
> #3  0x028f38a8 in BufferedAudioConverter::FillBuffer ()
> No symbol table info available.
> #4  0x028f364c in AudioConverterFillComplexBuffer ()
> No symbol table info available.
> #5  0x01f241b0 in macosx_audio_decoder_chain (pad=0xee0000,
> buf=0x631a000) at audiodecoders.c:501
>
> #0  0x0290ffbc in CodecConverter::DecoderFillBuffer ()
> #1  0x028f3a5c in AudioConverterChain::RenderOutput ()
> #2  0x028f38a8 in BufferedAudioConverter::FillBuffer ()
> #3  0x028f364c in AudioConverterFillComplexBuffer ()
> #4  0x01f241b0 in macosx_audio_decoder_chain (pad=0x0, buf=0x631a000)
> at audiodecoders.c:501
>
> #0  0x02980c34 in dyld_stub_AudioCodecAppendInputData ()
> #1  0x029100a0 in CodecConverter::DecoderFillBuffer ()
> #2  0x028f3a5c in AudioConverterChain::RenderOutput ()
> #3  0x028f38a8 in BufferedAudioConverter::FillBuffer ()
> #4  0x028f364c in AudioConverterFillComplexBuffer ()
> #5  0x01f241b0 in macosx_audio_decoder_chain (pad=0xee0000,
> buf=0x631a000) at audiodecoders.c:501
>
>  Do you have any hints as to why CodecConverter::DecoderFillBuffer()
> would never return ?
>
>  Thanks in advance, you'll find the relevant parts of code below,
>
>     Edward
>
>
>
> static OSStatus
> process_buffer_cb (AudioConverterRef inAudioConverter,
>    UInt32 * ioNumberDataPackets,
>    AudioBufferList * ioData,
>    AudioStreamPacketDescription ** outDataPacketDescription,
>    MacOSXAudioDecoder * macosx)
> {
>  gint len;
>  AudioStreamPacketDescription aspd;
>
>  GST_LOG_OBJECT (macosx, "ioNumberDataPackets:%lu, iodata:%p,
> outDataPacketDescription:%p",
>                 *ioNumberDataPackets,
>                 ioData,
>                 outDataPacketDescription);
>  if (outDataPacketDescription)
>    GST_LOG ("*outDataPacketDescription:%p",
>            *outDataPacketDescription);
>
>  ioData->mBuffers[0].mData = NULL;
>  ioData->mBuffers[0].mDataByteSize = 0;
>  if (macosx->prevdata)
>    g_free (macosx->prevdata);
>
>  len = gst_adapter_available (macosx->adapter);
>
>  if (len) {
>    ioData->mBuffers[0].mData = gst_adapter_take (macosx->adapter,
> len);
>    macosx->prevdata = ioData->mBuffers[0].mData;
> #if 1
>  /* if we have a valid outDataPacketDescription, we need to fill it */
>  if (outDataPacketDescription) {
>    /* mStartOffset : the number of bytes from the start of the
> buffer to the
>     * beginning of the packet. */
>    aspd.mStartOffset = 0;
>    /* mVariableFramesInPacket : the number of samples frames of
> data in the
>     * packet. For formats with a constant number of frames per
> packet, this
>     * field is set to 0. */
>    aspd.mVariableFramesInPacket = 0;
>    /* mDataByteSize : The number of bytes in the packet. */
>    aspd.mDataByteSize = len;
>    *outDataPacketDescription = &aspd;
>  }
> #endif
>
>  } else {
>    macosx->prevdata = NULL;
>  }
>
>  ioData->mBuffers[0].mDataByteSize = len;
>
>  GST_LOG_OBJECT (macosx, "returning %d bytes at %p",
>      len, ioData->mBuffers[0].mData);
>
>  if (!len)
>    return 42;
>  return noErr;
> }
>
> chain() {
>    GstBuffer *outbuf;
>    OSErr oserr;
>    OSStatus status;
>    guint32 outsamples = macosx->bufferlist->mBuffers
> [0].mDataByteSize / 8;
>    guint32 savedbytes = macosx->bufferlist->mBuffers[0].mDataByteSize;
>    guint32 realbytes;
>
>    GST_LOG_OBJECT (macosx, "Calling FillBuffer(outsamples:%d ,
> outdata:%p)",
>        outsamples, macosx->bufferlist->mBuffers[0].mData);
>
>    /* Ask AudioConverter to give us data ! */
>    status = AudioConverterFillComplexBuffer (macosx->aconv,
>        (AudioConverterComplexInputDataProc) process_buffer_cb,
>        macosx, &outsamples, macosx->bufferlist, NULL);
>
>    if ((status != noErr) && (status != 42)) {
>      if (status < 0)
>        GST_WARNING_OBJECT (macosx,
>            "Error in AudioConverterFillComplexBuffer() : %d", status);
>      else
>        GST_WARNING_OBJECT (macosx,
>            "Error in AudioConverterFillComplexBuffer() : %"
> GST_FOURCC_FORMAT,
>            QT_FOURCC_ARGS (status));
>      ret = GST_FLOW_ERROR;
>      goto beach;
>
>  }
>
>
> On 3/19/07, William Stewart <email@hidden> wrote:
>> You have to know these - they are described in the files that is
>> storing the AAC data and there are APIs (AudioFileReadPackets for
>> instance) where you get the packet descriptions when you read the
>> file
>>
>> Bill
>>
>> On 17/03/2007, at 1:23 AM, Edward Hervey wrote:
>>
>> > Hi,
>> >
>> > On 3/17/07, William Stewart <email@hidden> wrote:
>> >> The packet descriptions have to be on the side that has the
>> >> compressed data - so if you are decoding, the input proc has to
>> >> provide packet descs for VBR. So, in the input proc you have to
>> >> provide these based on where they are in the AAC stream you are
>> >> getting.
>> >
>> >  Thanks for the info, so the missing packet description is
>> indeed in
>> > my input proc. As I explained, I can't request the information
>> to fill
>> > in those structures from quicktime/CA.
>> >  Supposing I only have framed AAC coming in, where could I find
>> some
>> > documentation about what I need to put in the packet description
>> > depending on the buffer I am returning ?
>> >
>> >  Thanks again,
>> >
>> >     Edward
>> >
>> >>
>> >> You are providing packet desc on the output side (which you
>> would do
>> >> if you were encoding - in that case you just provide enough
>> space for
>> >> that number of packet descs, and the converter fills it out).
>> >>
>> >> Bill
>> >>
>>
>> --
>> mailto:email@hidden
>> tel: +1 408 974 4056
>> _____________________________________________________________________
>> ___
>> __
>> "Much human ingenuity has gone into finding the ultimate Before.
>> The current state of knowledge can be summarized thus:
>> In the beginning, there was nothing, which exploded" - Terry
>> Pratchett
>> _____________________________________________________________________
>> ___
>> __
>>
>>
>
>
> --
> Edward Hervey
> Multimedia editing developer / Fluendo S.A.
> http://www.pitivi.org/

--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__




--
Edward Hervey
Multimedia editing developer / Fluendo S.A.
http://www.pitivi.org/
_______________________________________________
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: 
 >CPU at 100% [Was: AAC and AudioConverter error : '!pkd'] (From: "Edward Hervey" <email@hidden>)
 >Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd'] (From: William Stewart <email@hidden>)

  • Prev by Date: Re: simultaneous parameter changes
  • Next by Date: Re: auval and you
  • Previous by thread: Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
  • Next by thread: Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
  • Index(es):
    • Date
    • Thread