• 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: iPhone RemoteIO partial input render
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iPhone RemoteIO partial input render


  • Subject: Re: iPhone RemoteIO partial input render
  • From: William Stewart <email@hidden>
  • Date: Thu, 19 Nov 2009 11:03:54 -0800


On Nov 19, 2009, at 5:52 AM, Zachary Kulis wrote:

Hi,

I am using the RemoteIO audio unit to record audio samples and store
them in a circular queue (I've disabled buffer allocation in the audio
unit). I've noticed that AudioUnitRender() does not support partial
retrieval of the available input samples (iPhone OS 2.2.1-3.1).

Yes, this is true of all AU semantics. It follows a real-time model so you get what have to get, and supply what you have to supply, for a given period of time


If I
prepare an AudioBuffer struct with mDataByteSize set to fewer than the
available bytes (as provided by the input callback), then the
AudioUnitRender() function still returns *ALL* of the available bytes
and actually sets the mDataByteSize field to the number of bytes returned.

that sounds like a bug to me = a bug report would be good - but you shouldn't be doing this (and the AU should actually return an error)



I would like to be able to do the render (sample retrieval) operation in
two steps when wrapping around to the head of my circular queue. As it
is now, I must do a temporary render into a single buffer, and then do
two memcpy() operations from this temporary buffer to the circular queue
when wrapping to the head. This is hugely inefficient, as it would be
better just to write directly to the circular queue. However, I would
need to be able to perform two partial renders of the available input
samples.

yes, but the AU would probably end up having to do something like this anyway.


Why not have your ring buffer be a bit bigger than what you think you need. Then when you get to the wrap around, if you don't have enough room, then reset the "end point" and just start again from the beginning - that way you don't have to do the wrap around case as two entries, and your ring buffer just has an additional notion of a "valid range" that changes if there is a mis-match between the I/O size and the ring buffer size. In our normal uses, we try to match these two sizes


Am I missing something here, or is this a bug/unsupported feature of the
RemoteIO audio unit?

Its not how the AUs work. We wouldn't change this at this point

Bill


Thank you, Zachary _______________________________________________ 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

_______________________________________________ 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: 
 >iPhone RemoteIO partial input render (From: Zachary Kulis <email@hidden>)

  • Prev by Date: Re: iPhone RemoteIO timeline strange behavior
  • Next by Date: Re: Streaming Audio - AudioFileStream, CFReadStreamRead and AudioQueue
  • Previous by thread: iPhone RemoteIO partial input render
  • Next by thread: iPhone RemoteIO timeline strange behavior
  • Index(es):
    • Date
    • Thread