[Bug 743758] osxaudiosrc supports only 44100 sample rate on iOS

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=743758

--- Comment #44 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
(In reply to Arun Raghavan from comment #43)
> On systems that I'm familiar with (namely Linux with PulseAudio), you either
> configure your system for stereo output or 5.1 or 7.1 or whatever, and from
> that point on, you expect the output to match what you've configured it for.

On the system level, the user defines his speaker setup (through the Audio MIDI
Setup app).

On the app level, osxaudio configures the inner scope.

> So I guess I'd model what we do based on what the "standard" behaviour on
> the platform is -- with the higher level frameworks, does playing a 2ch
> stream on a 5.1ch output result in upmixing? If yes, then that's what
> developers and end-users expect, and playing out a partial set of channels
> would be incorrect.

I don't know other higher level frameworks on OS X, but we might as well regard
GStreamer is *the* higher level framework, since we're implementing a drop-in
system source/sink element.

In general, I'm fine with forcing people to use $some_element to upmix/downmix,
or to remove channels or to add silence channels (is there an element for
that?), as long as it doesn't come with performance implications.

If there's a performance implication, let's try and find a way to use the Core
Audio infrastructure to the maximum extent possible. For example, we can
consider only announcing caps with a channel-mask, and:
* adding a 'channel-mask' property that'll only accept subsets of the hardware
channel mask, and/or
* adding a 'force-channel-mask' property that'll make osxaudio accept an
arbitrary channel mask, and/or
* adding a 'no-channel-mask' property to enable my current behavior

I just want to be careful not to force unneeded overhead.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.