• 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: Edirol FA-101 and CoreAudio (Jeff Moore)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Edirol FA-101 and CoreAudio (Jeff Moore)


  • Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
  • From: Jeff Moore <email@hidden>
  • Date: Thu, 15 Sep 2005 15:35:20 -0700

The other case where the mDataByteSize field is filled out while the mData field is NULL comes up when a stream is disabled for a given IOProc using kAudioDevicePropertyIOProcStreamUsage. In this case, the AudioBuffer that corresponds to that stream in the ABL passed to the IProc will have it's mData field set to NULL.

The reason why starts out with the fact that not only doesn't the HAL pass an inNumberFrames argument to the IOProc, but the HAL also allows for non-audio data to be passed in to the IOProc in these ABLs. Thus, it is vital that this field be filled out even if the mData field is NULL so that the client knows how much time that particular call to the IOProc represents.

On Sep 15, 2005, at 11:54 AM, Doug Wyatt wrote:

On Sep 15, 2005, at 6:11, Roni Music wrote:

I think it would be good if you add the changes to the "afrecord" example.
That example have the same bug.



fixed for the next SDK rev, thanks


One thing is not clear to me:
Why must the mDataByteSize be num frames * sizeof(float)
when the mData pointer is NULL?


Beyond what Bill just wrote, I can't find any documentation that I may be contradicting when I say this ... but let's look at AUBase::DoRenderBus (in AUBase.h). Here we test to see if the caller passed a NULL buffer pointer. If he did, then we set things up to render into the element's own buffer list, render, then copy that internal buffer list (the list, not the buffer data) to the buffer list that the caller supplied. So the incoming buffer's mDataByteSize is ignored.


Really, the AU should only have to look at inNumberFrames to decide how much to render.

This was not true in the deprecated V1 Audio Unit spec (we're going back to 2002 here...) where the mDataByteSize really did have to be correct in all cases, because there was not an inNumberFrames parameter to the old function AudioUnitRenderSlice.

--
Doug Wyatt
Core Audio, Apple

_______________________________________________
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



--

Jeff Moore
Core Audio
Apple


_______________________________________________ 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: Edirol FA-101 and CoreAudio (Jeff Moore) (From: "Roni Music" <email@hidden>)
 >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: William Stewart <email@hidden>)
 >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: "Roni Music" <email@hidden>)
 >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: William Stewart <email@hidden>)
 >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: "Roni Music" <email@hidden>)
 >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: Doug Wyatt <email@hidden>)

  • Prev by Date: IMPORTANT: Tiger QuicKTime 7.0.2 SDK SU Problem
  • Next by Date: Re: AudioConverterConvertBuffer() and interleaved data
  • Previous by thread: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
  • Next by thread: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
  • Index(es):
    • Date
    • Thread