• 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: ExtAudioFileRead() + mp3 + 10.5 Crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ExtAudioFileRead() + mp3 + 10.5 Crash


  • Subject: Re: ExtAudioFileRead() + mp3 + 10.5 Crash
  • From: William Stewart <email@hidden>
  • Date: Mon, 29 Oct 2007 11:09:02 -0700

Please report bugs at:

http://bugreporter.apple.com
- providing the listing that you do here would be excellent. The problem with email is that it gets lost and isn't able to be tracked.


As for you previous example, I have a big concern about it:
>>>
The relevant code:
------------------
OSStatus readCallback(void *                        enhancer,
                     AudioUnitRenderActionFlags *  ioActionFlags,
                     const AudioTimeStamp *        inTimeStamp,
                     UInt32                        inBusNumber,
                     UInt32                        inNumberFrames,
                     AudioBufferList *             ioData)
{
   ...

   //  DEBUG
   SInt64 offset;
   ExtAudioFileTell(myFileRef, &offset);
   printf("offset: %lld\n", offset);

   //  fill the buffer with audio data
   UInt32 readFrames = inNumberFrames;
   OSStatus error = ExtAudioFileRead(myFileRef, &readFrames, ioData);
>>>

If this audio unit is on the I/O Thread (if it is connected to AUHAL for instance), then you shouldn't do this as it will lead to random dropouts in your audio rendering.

Reading files from the disk can block for an indeterminant period of time. The I/O thread is on a tight deadline and has to provide its data within that deadline, so you can't do activities (like read/write to a disk, blocking semaphores, etc) on that thread.

We have an example in the SDK (/Developer/Examples/CoreAudio/ SimpleSDK) called PlayFile - it uses the AUFilePlayer audio unit to provide data from a file to an audio unit for further processing/ mixing/etc... AUFilePlayer's internal implementation has another thread upon which it reads the file data and converts it to a format suitable for the AU world.

If your audio unit is not executing on the I/O thread, then what you are doing here is fine.

Bill

_______________________________________________
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: 
 >Re: ExtAudioFileRead() + mp3 + 10.5 Crash (From: patrick machielse <email@hidden>)

  • Prev by Date: Re: Firewire audio testing
  • Next by Date: Re: ExtAudioFileWrapAudioFileID crashing in Leopard
  • Previous by thread: Re: ExtAudioFileRead() + mp3 + 10.5 Crash
  • Next by thread: Having AudioConverter recognise custom AudioCodec components
  • Index(es):
    • Date
    • Thread