... and fallback to gst_audio_info_set_format for not yet supported layouts.
Fix audio playback on iOS 12.
Based on patch from Byron Schiel <byron@canary.is>
https://bugzilla.gnome.org/show_bug.cgi?id=796919
Fixes a negotiation error seen when trying to playback of a .MOV file with
a mono AAC audio stream decoded by avcdec_aac that doesn't set channel-mask
field but sink was requiring channel-mask=0x3.
For 1ch or 2ch devices, we just need to set the caps to allow both
options since CoreAudio will up/downmix appropriately.
Also fixes the condition for the 2ch case to be exact, rather than at
least 2 channels since the downmix will not take place in the >stereo
case.
We need to initialize the AudioUnit early to be able to probe the
underlying device, but according to the AudioUnitInitialize() and
AudioUnitUninitialize() documentation, format changes should be done
while the AudioUnit is uninitialized. So we explicitly uninitialize the
AudioUnit during a format change and reinitialize it when we're done.
_audio_unit_property_listener is called either from a Core Audio thread
or as a result of a Core Audio API (e.g. AudioUnitInitialize)
from our own thread. In the latter case, osxbuf can be already locked
(GStreamer's mutex is not recursive).
We introduce the flag cached_caps_valid and use it instead of nullifying
cached_caps when we cannot lock on osxbuf.
https://bugzilla.gnome.org/show_bug.cgi?id=743758
- Probing caps is unified between source and sink
- Hardware stream format is now reported as preferred capabilities
(dynamically updated when hardware configuration changes)
- Get hardware channel layout from Remote IO just like from HAL
- More comprehensive mapping between AudioChannelLabel and
GstAudioChannelPosition
- Support for unpositioned channel layouts
- Announce stereo-mono upmixing/downmixing in caps
https://bugzilla.gnome.org/show_bug.cgi?id=743758
Fixes stuttering audio when iOS AU is resampling. To make AU resample,
one has to request a rate that differs from AVAudioSession's
sampleRate. The resampling itself is not the culprit, but rather our
API misuse.
AudioUnitRender modifies the mDataByteSize members with the
actual read bytes count. Therefore, they must be reinitialized
before each AudioUnitRender. (The buffers themselves can be
preallocated.)
The "stutter" was caused by one AudioUnitRender making the buffer
too small for other AudioUnitRender invocations, making them fail
with -50 (paramErr). By way of luck, when AU didn't resample, all
AudioUnitRender invocations read the same number of bytes.
(This patch addresses some non-interleaved audio concerns, but
at this moment the elements do not support non-interleaved audio
and non-interleaved is untested.)
https://bugzilla.gnome.org/show_bug.cgi?id=744922
Now that device selection has no sink/source-specific bits, we can have
generic device selection for this path. We do need to now track state
changes so we can look up the final device_id once the device is open,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=740987
