mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-08 18:39:54 +00:00
1a8610f8f8
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 |
||
|---|---|---|
| .. | ||
| acmenc | ||
| acmmp3dec | ||
| androidmedia | ||
| applemedia | ||
| bluez | ||
| d3dvideosink | ||
| decklink | ||
| directsound | ||
| dshowdecwrapper | ||
| dshowsrcwrapper | ||
| dshowvideosink | ||
| dvb | ||
| fbdev | ||
| kms | ||
| msdk | ||
| nvenc | ||
| opensles | ||
| shm | ||
| tinyalsa | ||
| uvch264 | ||
| vcd | ||
| vdpau | ||
| wasapi | ||
| winks | ||
| winscreencap | ||
| Makefile.am | ||
| meson.build | ||