• 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: Multiple RemoteIO
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple RemoteIO


  • Subject: Re: Multiple RemoteIO
  • From: Aran Mulholland <email@hidden>
  • Date: Sat, 16 Apr 2016 07:30:14 +1000

Lovely resources Jonatan, I feel like copying them in case you ever remove them, beautifully laid out as well. A+ :) from me.

On Fri, Apr 15, 2016 at 7:25 PM, Jonatan Liljedahl <email@hidden> wrote:
> Date: Thu, 14 Apr 2016 09:35:04 -0500
> From: Lucas Goossen <email@hidden>
> To: CoreAudio API <email@hidden>
> Subject: Multiple RemoteIO
> Message-ID: <email@hidden">email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I would like to be able to have access to hardware while simletaiously registering a remoteIO with IAA. I know this is possible becasue Audiobus does this when you create a ABFilterPort with processBlock. The filter port created has its own remoteIO that it uses for IAA under the hood, but I can still use my own remoteIO for hardware. When I try to replicate this myself by the whole AudioComponentFindNext - AudioComponentInstanceNew sequence the second remoteIO seems to kill the first. What am i missing?

Yes, this is totally possible, and it's what I do in my app AUM - Audio Mixer:

I have a main RIO unit for hardware I/O, that I never publish as an
IAA connectable node.

    AudioComponentDescription cd = {kAudioUnitType_Output,
kAudioUnitSubType_RemoteIO, kAudioUnitManufacturer_Apple, 0, 0};
    AudioComponent comp = AudioComponentFindNext(NULL, &cd);
    OSStatus status = AudioComponentInstanceNew(comp, &unit);
    etc...
    And don't forget to AudioUnitInitialize() your unit.

I set the client-side streamFormat to non-interleaved float, with the
same number of input/output channels as the currently connected
hardware route.

Also I add a property listener on kAudioUnitProperty_StreamFormat to
be able to observe sample rate and channel-count changes and sync the
client-side stream format to avoid automatic sample-rate conversion by
the system. Also the usual enable IO for both input and output using
kAudioOutputUnitProperty_EnableIO, set
kAudioUnitProperty_MaximumFramesPerSlice to 4096, and set my main
render callback with kAudioUnitProperty_SetRenderCallback.

Then, I create 8 additional RIO units for my IAA output ports:

Same thing to create RIO units for these, except I disable input since
they are output ports and not filter ports. The render callback for
these units provide the audio to the host. I set the stream format to
stereo float using the current sample rate (and in the main RIO unit
StreamFormat listener callback I update the format on these IAA units
as well!)

Then I publish the IAA units, if using Audiobus this is taken care of
by creating an ABSenderPort for each unit and adding it to the
audiobusController.

I have some various developer notes regarding iOS audio and IAA here:
http://lijon.github.io

Important stuff regarding multiple IAA ports:
http://lijon.github.io/iaa_quirks.html

And how sample rates and stream formats work in IAA (there's actually
a chain of 3 different streamFormats, with 2 potential places for
sample rate conversion, in each direction of the host<->node audio
signal flow): http://lijon.github.io/iaa_sample_rates.html

--
/Jonatan
http://kymatica.com

 _______________________________________________
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

  • Follow-Ups:
    • Re: Multiple RemoteIO
      • From: Jonatan Liljedahl <email@hidden>
References: 
 >Multiple RemoteIO (From: Jonatan Liljedahl <email@hidden>)

  • Prev by Date: Multiple RemoteIO
  • Next by Date: Re: Multiple RemoteIO
  • Previous by thread: Multiple RemoteIO
  • Next by thread: Re: Multiple RemoteIO
  • Index(es):
    • Date
    • Thread