Directsoundsrc/sink have multiple issues, most of which cannot be
fixed at all because the API is deprecated and is implemented as a
compatibility wrapper around WASAPI since Vista.
Users and developers should now use the wasapisrc/sink elements, and
future development efforts should go towards that.
The main advantage is that our sleeps can be interrupted in case of
an src_reset(). Earlier, we would need to wait for a read to complete
before we could do a reset, which could take a long time.
https://bugzilla.gnome.org/show_bug.cgi?id=781249
Earlier, the plugin was ignoring those settings and blindly setting
buffer-time to 2 seconds and latency-time to 200ms, which forced all
pipelines to have a minimum latency of 200ms + sink latency.
The values of segsize and segtotal were also not derived correctly.
Now we obey these values, and you can get close to the previous
behaviour by setting buffer-time and latency-time manually. Note that
they are set in microseconds.
As a consequence, when we haven't received enough data from the
device, we now sleep for a time proportional to the data remaining.
However, Directsound is a deprecated API so it maintains its own
software ringbuffer which updates at arbitrary intervals. Hence we
might have to wait a full segsize to get the last 10% of data. To
avoid tight loops, we clamp our sleep floor at 10ms.
In my testing, this keeps the wakeups not-too-high (proportional to
the latency-time set on the source). Further improvements should be
made by fixing the WASAPI audio source plugin instead of this.
Directsound is deprecated and as the comments explain, it is
impossible to get low latency, decent quality, or good performance
from it.
Based on a patch by Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781249
This reverts commit 6d256d9908.
It was configuring the period/buffer size in a way that often causes
drop-outs or complete underruns. Needs further investigation.
segsize should be based on latency-time, and must be a multiple of the
frame size. segtotal should be based on buffer-time and segsize.
This prevents errors caused by outputting buffers that are not a
multiple of the frame size, and actually makes the buffer-time and
latency-time properties do what they're supposed to do.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.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 device name and descriptions returned are in the locale encoding, not
UTF8. Our device name property is in UTF8 though, so we need to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=756948
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
Casting to UINT from HMIXER generates the following warning with
64bit Windows target MinGW:
gstdirectsoundsrc.c: In function 'gst_directsound_src_mixer_find':
gstdirectsoundsrc.c:733:30: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
mmres = mixerGetDevCaps ((UINT) dsoundsrc->mixer,
^
cc1: all warnings being treated as errors
We can use portable GPOINTER_TO_UINT() macro for this propose.
https://bugzilla.gnome.org/show_bug.cgi?id=754756
gst_pad_get_pad_template_caps() returns a reference which is unreferenced,
so creating a copy using gst_caps_copy() results in a reference leak.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=734536
One set of CFLAGS for all DirectX-based plugins. Correct header/library
checks for DirectX-based-plugins. Remove unused variable and label in
directsoundsrc.
Fixes#593068.
Original commit message from CVS:
* docs/plugins/gst-plugins-bad-plugins.args:
Remove directsoundsink property doc as this sink use the mixer
interface now.
* docs/plugins/gst-plugins-bad-plugins.interfaces:
Add interfaces implemented by Windows sinks.
* sys/directsound/gstdirectsoundsink.c:
* sys/directsound/gstdirectsoundsink.h:
Remove directsoundsink property and implement the mixer interface.
* win32/vs6/gst_plugins_bad.dsw:
* win32/vs6/libgstdirectsound.dsp:
Update project files.
* gst-libs/gst/dshow/gstdshow.cpp:
* gst-libs/gst/dshow/gstdshow.h:
* gst-libs/gst/dshow/gstdshowfakesink.cpp:
* gst-libs/gst/dshow/gstdshowfakesink.h:
* gst-libs/gst/dshow/gstdshowfakesrc.cpp:
* gst-libs/gst/dshow/gstdshowfakesrc.h:
* gst-libs/gst/dshow/gstdshowinterface.cpp:
* gst-libs/gst/dshow/gstdshowinterface.h:
* win32/common/libgstdshow.def:
* win32/vs6/libgstdshow.dsp:
Add a new gst library which allow to create internal Direct Show
graph (pipelines) to wrap Windows sources, decoders or encoders.
It includes a DirectShow fake source and sink and utility functions.
* sys/dshowsrcwrapper/gstdshowaudiosrc.c:
* sys/dshowsrcwrapper/gstdshowaudiosrc.h:
* sys/dshowsrcwrapper/gstdshowsrcwrapper.c:
* sys/dshowsrcwrapper/gstdshowsrcwrapper.h:
* sys/dshowsrcwrapper/gstdshowvideosrc.c:
* sys/dshowsrcwrapper/gstdshowvideosrc.h:
* win32/vs6/libdshowsrcwrapper.dsp:
Add a new plugin to wrap DirectShow sources on Windows.
It gets data from any webcam, dv cam, micro. We could add
tv tunner card later.
Original commit message from CVS:
* configure.ac:
* sys/directdraw/Makefile.am:
* sys/directsound/Makefile.am:
Add DIRECTDRAW_CFLAGS and DIRECTSOUND_CFLAGS to Makefile.am; save
and restore the various flags in the directdraw/directsound
detection section. Apparently improves cross-compiling for win32
with mingw32 under some circumstances (#437539).
