Below fallback paths were introduced in
9759810d82
if setting period time after buffer time failed :
1) Set period time and then buffer time if it doesn't work
2) Set only buffer time
3) Set only period time
These all were not functioning properly since they were using old
copy of snd_pcm_hw_params_t which already had some fields set
as per previous try and this was causing issues as driver was
referring to that old value while trying to set them again in
fallback paths.
So now we always use the initial copy of snd_pcm_hw_params_t
for every fallback and same is also being done at
557c429510
Also we change the sequence to set period time earlier than
buffer time since period bytes being the smaller unit, most of the times
if underlying alsa device has a dependency then it is of period bytes
to be a multiple of some value (as per underlying DMA constraint)
and rest of the parameters like buffer bytes need to be adjusted
as per period bytes.
The same sequence is also followed in alsa-utils at
9b621eeac4
Fix 2) and 3) scenarios by returning success if the exclusive setting is passed
and not doing any further setting for buffer time or period time.
Add new fallback path of not setting any buffer time and period time
if all above fallback paths fail. The same is also being
followed at aforementioned pulseaudio commit.
In case of alsasink, remove the retry goto label, since it is not
required anymore as fallback paths take care of setting default
values if driver is not accepting any of the fallback paths.
Use separate label for exit to free params structs and return err
code. This also fixes leak in no_rate goto path in alsasink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1212>
If the alsasink thread starts the write loop but another thread pauses
the underlying alsa device, the sink thread will endlessly loop.
snd_pcm_writei() will return 0 if the state is SND_PCM_STATE_PAUSED
and the loop will never make any progress.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1097>
This because underlying driver may have constraint on
buffer size to be dependent on period size, so period
time needs to be set first.
For e.g. Xilinx ASoC driver requires
buffer size to be multiple of period size for it's DMA
operation.
alsa-utils also set period time first as seen in below commit :
9b621eeac4
Tested it on zcu106 board with HDMI based record and playback.
Also tested on Intel PC using Logitech C920 Webcam mic and ALC887-VD
Analog for playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1040>
```
../subprojects/gst-plugins-base/ext/alsa/gstalsamidisrc.c:201:54: error: converting the result of '<<' to a boolean always evaluates to false [-Werror,-Wtautological-constant-compare]
snd_seq_ev_schedule_real (&ev, alsamidisrc->queue, SND_SEQ_TIME_MODE_ABS,
^
/usr/include/alsa/seq_event.h:215:34: note: expanded from macro 'SND_SEQ_TIME_MODE_ABS'
```
The ALSA API expects 0 or 1 here and will then add the flags accordingly,
and that's also what other code using this API does.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/777>
Removing gstalsadeviceprobe.[ch] as it was a relique from the 0.10
century.
This doesn't implement device monitoring but only probing, monitoring
should be implemented in its own commit.
This reverts commit 69c3c31608.
All devices have the same name, they are duplicated with pulseaudio one
and the provided does not respond to HW being plugged/unplugged. I think
it's not ready for 1.16.
Alsasrc introduced delay_lock in commit 519f85a43e73efb8f3fb2c7be45226e
because alsa-lib is not thread safe for the same handle.
Alsasrc uses the same threading pattern, it should be locked too.
https://bugzilla.gnome.org/show_bug.cgi?id=746015
Make buffer timestamps more accurate and, more importantly, actually
representative of the MIDI events timing.
Previously, buffers were only sent with timetamps aligned at a 10ms
boundary which was just wrong, now the buffer timestamp represents the
real time of the MIDI event.
Conveniently, the ALSA sequencer API supports scheduling events in the
future so the sequencer infrastructure can be used to have the tick
delivered at the right time, avoiding any custom scheduling mechanism.
The ticks scheduling starts on the first transition to PLAYING, and the
delay is also calculated when the pipeline goes into PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=787683
When setting the "ports" property the value is duplicated but it's not
freed when the elements stops.
Reported by Valgrind (example run with "alsamidisrc ports=128:0"):
6 bytes in 1 blocks are definitely lost in loss record 30 of 1,911
at 0x4C2BBEF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5411528: g_malloc (gmem.c:94)
by 0x542A9FE: g_strdup (gstrfuncs.c:363)
by 0x775211E: gst_alsa_midi_src_set_property (gstalsamidisrc.c:284)
by 0x5184A4D: object_set_property (gobject.c:1439)
by 0x5184A4D: g_object_setv (gobject.c:2245)
by 0x51859DD: g_object_set_property (gobject.c:2529)
by 0x4F0474C: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4F065C8: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4F07557: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4EFE3EE: gst_parse_launch_full (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4EFE673: gst_parse_launchv_full (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
https://bugzilla.gnome.org/show_bug.cgi?id=787683
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
The only way for ALSA to expose a position-less multi channels is to
return an array full of SND_CHMAP_MONO. Converting this to a
GST_AUDIO_CHANNEL_POSITION_MONO array would be invalid as
GST_AUDIO_CHANNEL_POSITION_MONO is meant to be used only with one
channel.
Fix this by using GST_AUDIO_CHANNEL_POSITION_NONE which is meant to be
used for position-less channels.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
