The ringbuffer does allow renegotiation, so we do not have to report
fixed caps once it is acquired (based on a similar patch for the sink
side by Ilya Konstantinov <ilya.konstantinov@gmail.com>).
Once osxaudiosink's device is open, it fixates on the initial caps and
refuses to accept new caps. This is erroneous since the Audio Unit is
can accept a new ASBD, and GstAudioRingBuffer supports reconfiguration
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=743925
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
After creating the ringbuffer we have to set the device on the ringbuffer as
it defaults to kAudioDeviceUnknown. At this point it can't have changed to
anything else yet and we don't have to notify about changes to the sink/src
"device" property. It's also not a good idea because GstAudioBaseSrc has the
object lock taken while the ringbuffer is created, which might cause a
deadlock if something calls back into the element from "notify::device".
Once the base class is done with the NULL_TO_READY state change, it has opened
the device via the ringbuffer and this might have chosen a different device.
Especially if we initially used kAudioDeviceUnknown. Also notify about this
property change as initially intended by this code.
It's unlikely that setting a channel layout will do much for AC3/DTS
streams. If we find at some point that it does make sense, we can
perform the structure copying unconditionally (i.e., the current code is
wrong, since AC3/DTS will get two structures now - one with the channel
layout, one without).
https://bugzilla.gnome.org/show_bug.cgi?id=740987
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
This is conceptually the right thing to do, and allows us to correctly
catch errors in device selection as well, which we could not do while
creating the ringbuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=740987
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
And especially also consider update versions, e.g. 10.5 with updates
will be 1051 or similar and thus bigger than MAC_OS_X_VERSION_10_5 but
still won't have the API we want to use.
Set channel-mask according to sink's layout in case of stereo layout.
Also initialize and reset the mask when an unrecognized channel is detected.
https://bugzilla.gnome.org/show_bug.cgi?id=698224
Changes include the following:
* Update classname references
* Replace GST_BOILERPLATE_FULL with G_DEFINE_TYPE
* Use new GstAudioInfo struct and methods
* Use new buffer memory allocation scheme
Conflicts:
sys/osxaudio/gstosxaudioringbuffer.c
