Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify formats when working with input/output scopes on an AudioUnit's input/output elements. #60

Open
mitchmindtree opened this issue Apr 23, 2018 · 1 comment
Labels

Comments

@mitchmindtree
Copy link
Member

mitchmindtree commented Apr 23, 2018

Each audio unit actually has 4 formats:

  • Input and output scope formats for the input element.
  • Input and output scope formats for the output element.

#47 is related to this but perhaps not general enough in its approach to solving this.

Perhaps we should change stream_format to always require taking the Scope and Element as arguments? cc @plietar

@plietar
Copy link

plietar commented Apr 23, 2018

It's been a really long time since I've used CA, so this is just from what I've been able to gather from the docs.

In general AU don't necessarily have one input and output element.

  • For I/O units, there are two elements, input for capture and output for playback. On the input (capture) element only the outputs scope's format is configurable, the input's scope's format is determined from the hardware. On the output (playback) element only the input scope's is used (and only if a render callback is connected. If another AU is connected then that unit's output scope's format is used). The output scope's format is determined from the hardware.

  • For Mixer elements there is a single output element and many inputs. The output element's output scope's sample rate can be configured, but not the rest of the format. The input elements' input scope's format is configurable if a render callback is used, otherwise the connected AU's format is.

I think AudioUnit should only expose set_property/get_property with an integer as the element. stream_format/set_stream_format should be provided by some AU-specific types. For example the IO unit type would expose a set_playback_format and set_capture_format. The Mixer unit type may expose a set_output_sample_rate and a set_input_format for each of it's channels.

Or the AudioUnit could expose the stream_format/set_stream_format methods, but with an integer element and a Scope and it is up to the caller to use the right one.

dmski added a commit to dmski/coreaudio-rs that referenced this issue May 9, 2019
As i understand it, an audio unit can have several inputs and several outputs,
and an 'element' is just an index of one of those (https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/TheAudioUnit/TheAudioUnit.html).

Therefore, it's should be possible, for example, to have several render callbacks for a single audio unit.
An example would be a crossfade unit with 2 inputs: it'll have 2 elements in its input scope
and 1 in output scope, and it'll require either two render callbacks (one for each input),
or two upstream audio units.

This changes Element to be just a number and adds explicit element parameter to all the places
where it hasn't been present before (i.e. setting callbacks and input/output stream formats).

This relates to the issue RustAudio#60 and PR RustAudio#47.
dmski added a commit to dmski/coreaudio-rs that referenced this issue May 9, 2019
As i understand it, an audio unit can have several inputs and several
outputs, and an 'element' is just an index of one of those.
(https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/TheAudioUnit/TheAudioUnit.html).

Therefore, it's should be possible, for example, to have several render
callbacks for a single audio unit. An example would be a crossfade unit
with 2 inputs: it'll have 2 elements in its input scope and 1 in output
scope, and it'll require either two render callbacks (one for each input),
or two upstream audio units.

This changes Element to be just a number and adds explicit element
parameter to all the places where it hasn't been present before
(i.e. setting callbacks and input/output stream formats).

This relates to the issue RustAudio#60 and PR RustAudio#47.
dmski added a commit to dmski/coreaudio-rs that referenced this issue May 9, 2019
As i understand it, an audio unit can have several inputs and several
outputs, and an 'element' is just an index of one of those.
(https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/TheAudioUnit/TheAudioUnit.html).

Therefore, it's should be possible, for example, to have several render
callbacks for a single audio unit. An example would be a crossfade unit
with 2 inputs: it'll have 2 elements in its input scope and 1 in output
scope, and it'll require either two render callbacks (one for each input),
or two upstream audio units.

This changes Element to be just a number and adds explicit element
parameter to all the places where it hasn't been present before
(i.e. setting callbacks and input/output stream formats).

I also had to change handling of render callbacks a bit, since there can
now be more than one of them for a single audio unit.

This relates to the issue RustAudio#60 and PR RustAudio#47.
dmski added a commit to dmski/coreaudio-rs that referenced this issue May 12, 2019
As i understand it, an audio unit can have several inputs and several
outputs, and an 'element' is just an index of one of those.
(https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/TheAudioUnit/TheAudioUnit.html).

Therefore, it's should be possible, for example, to have several render
callbacks for a single audio unit. An example would be a crossfade unit
with 2 inputs: it'll have 2 elements in its input scope and 1 in output
scope, and it'll require either two render callbacks (one for each input),
or two upstream audio units.

This changes Element to be just a number and adds explicit element
parameter to all the places where it hasn't been present before
(i.e. setting callbacks and input/output stream formats).

I also had to change handling of render callbacks a bit, since there can
now be more than one of them for a single audio unit.

This relates to the issue RustAudio#60 and PR RustAudio#47.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants