The newly exposed vmethods are pause, resume, stop and clear_all.
The existing reset vmethod is deprecated.
The audio sink will fallback to calling reset if pause or stop
are not provided and will fallback to calling start if
resume is not provided. There is no default clear_all
implementation.
Existing audio sinks continue to work as before.
This change is useful for sinks that need to distinguish
between a pause and a stop (currently both are handled
by a reset) and is needed for https://bugzilla.gnome.org/show_bug.cgi?id=788362https://bugzilla.gnome.org/show_bug.cgi?id=788361
When using multichannel audio data and being needed to reorder channels,
audio data is not copied correctly because destination address of
memcpy is wrong.
For example, the following command
$ gst-launch-1.0 pulsesrc ! audio/x-raw,channels=6,format=S16LE ! filesink location=test.raw
will reproduce this issue if there is 6-ch audio input device.
This commit fixes that.
The detailed process of this issue is as follows:
1. gst-launch-1.0 calls gst_pulsesrc_prepare (gst-plugins-good/ext/pulse/pulsesrc.c)
1466 gst_pulsesrc_prepare (GstAudioSrc * asrc, GstAudioRingBufferSpec * spec)
1467 {
(skip...)
1480 {
1481 GstAudioRingBufferSpec s = *spec;
1482 const pa_channel_map *m;
1483
1484 m = pa_stream_get_channel_map (pulsesrc->stream);
1485 gst_pulse_channel_map_to_gst (m, &s);
1486 gst_audio_ring_buffer_set_channel_positions (GST_AUDIO_BASE_SRC
1487 (pulsesrc)->ringbuffer, s.info.position);
1488 }
In my environment, after line 1485 is processed, position of spec and s are
spec->info.position[0] = 0
spec->info.position[1] = 1
spec->info.position[2] = 2
spec->info.position[3] = 6
spec->info.position[4] = 7
spec->info.position[5] = 8
s.info.position[0] = 0
s.info.position[1] = 6
s.info.position[2] = 2
s.info.position[3] = 1
s.info.position[4] = 7
s.info.position[5] = 8
The values of spec->info.positions equal
GST_AUDIO_BASE_SRC(pulsesrc)->ringbuffer->spec->info.positions.
2. gst_audio_ring_buffer_set_channel_positions calls
gst_audio_get_channel_reorder_map.
3. Arguments of gst_audio_get_channel_reorder_map are
from = s.info.position
to = GST_AUDIO_BASE_SRC(pulsesrc)->ringbuffer->spec->info.positions
At the end of this function, reorder_map is set to
reorder_map[0] = 0
reorder_map[1] = 3
reorder_map[2] = 2
reorder_map[3] = 1
reorder_map[4] = 4
reorder_map[5] = 5
4. Go back to gst_audio_ring_buffer_set_channel_positions and
2065 buf->need_reorder = TRUE;
is processed.
5. Finally, in gst_audio_ring_buffer_read,
1821 if (need_reorder) {
(skip...)
1829 memcpy (data + i * bpf + reorder_map[j] * bps, ptr + j * bps, bps);
is processed and makes this issue.
As said in its doc GST_AUDIO_CHANNEL_POSITION_NONE is meant to be used
for "position-less channels, e.g. from a sound card that records 1024
channels; mutually exclusive with any other channel position".
But at the moment using such positions would raise a
'g_return_if_reached' warning as gst_audio_get_channel_reorder_map()
would reject it.
Fix this by preventing any attempt to reorder in such case as that's not
what we want anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
For alaw/mulaw we should also try to initialize the channel positions in the
ringbuffer's audio info. This allow pulsesink to directly use the channel
positions instead of using the default zero-initialized ones, which doesn't
work well.
https://bugzilla.gnome.org/show_bug.cgi?id=751144
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.
gst_audio_ring_buffer_set_channel_positions() checks whether the given
positions are identical with the current setup and returns
immediately if so. But it also clears need_reorder flag before this
comparison, thus this flag might be wrongly cleared if the function is
called twice with the same channel positions.
Move the flag clearance after the check.
https://bugzilla.gnome.org/show_bug.cgi?id=709754
Make it possible for subclasses to provide the timestamp (as an absolute time
against the pipeline clock) of the last read data.
Fix up alsa to provide the timestamp received from alsa. Because the alsa
timestamps are in monotonic time, we can only do this when the monotonic clock
has been selected as the pipeline clock.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=635256
