Commit Graph

1707 Commits

Author SHA1 Message Date
Quantum
f28084e653 [client] core: remove state tracking in core_updateOverlayState
The state is never updated when a message box is dismissed, so the
cursor is never displayed when a second message box shows up.

The only other caller, app_setOverlay, has state tracking already.
2022-03-19 10:04:23 +11:00
Geoffrey McRae
3a8cb6a613 [client/common] fixes for issues detected through static analysis. 2022-03-07 10:14:52 +11:00
Tudor Brindus
a3820536ab [client] overlay: make "Show timing graphs" checkbox consistent in case 2022-03-06 17:21:32 +11:00
Shootfast
48cf099638 [client] input: fix confine_pointer argument marshalling
Under Wayland, if the mouse pointer is disconnected whilst captured
(like say via KVM switch), the waylandWarpPointer code will be called
but the pointer will be NULL. This results in the cryptic message:

error marshalling arguments for confine_pointer (signature noo?ou): null value passed for arg 2
Error marshalling request: Invalid argument

This patch adds a check on the wlWm.pointer pointer before attempting
to warp the pointer, and avoids the crash.
2022-03-05 09:33:45 +11:00
Tudor Brindus
88d60d4b3d [client] enforce building with -Wstrict-prototypes 2022-02-28 11:56:26 +11:00
Tudor Brindus
3189c7bcd6 [client] kb: update for ImGui 1.87 2022-02-28 11:56:26 +11:00
Chris Spencer
72033f3822 [client] audio: reduce hardcoded minimum latency
The current minimum target latency is partially based upon the default qemu
behaviour whereby audio packets are delivered in a sawtooth pattern, with
packet timestamps drifting between 5ms above and below the measured clock.
This 5ms error is baked into the minimum target latency to avoid
underrunning.

This sawtooth pattern can be reduced by specifying a lower timer period in
the qemu configuration, so remove it from the hardcoded minimum latency and
add it to the default configurable buffer latency instead. This allows
users that have configured their VM appropriately to reduce the overall
latency.
2022-02-28 11:52:16 +11:00
Chris Spencer
c2523be4b4 [client] audio: reduce resampler latency
The best quality resampler has an intrinsic latency of about 3ms, and the
processing itself takes another 1-2ms per 10ms block. The faster setting
has an intrinsic latency of about 0.4ms, with about 0.04ms processing time.
This makes for an overall saving of about 4ms, with negligible loss in
quality.
2022-02-27 23:47:43 +11:00
Chris Spencer
7efc274e81 [client] audio: use block comments 2022-02-27 23:47:43 +11:00
Chris Spencer
7c2d493bb5 [client] audio: add latency tuning parameter
This adds a new `audio:bufferLatency` option which allows the user to
adjust the amount of buffering LG does over the absolute bare minimum. By
default, this is set large enough to absorb typical timing jitter from
Spice. Users may reduce this if they care more about latency than audio
quality.
2022-02-25 20:41:47 +11:00
Chris Spencer
9908b737b0 [client] audio: make the requested audio device period size configurable
This adds a new `audio:periodSize` option which defaults to 2048 frames.
For PipeWire, this controls the `PIPEWIRE_LATENCY` value. For PulseAudio,
the controls the target buffer length (`tlength`) value.
2022-02-25 20:41:47 +11:00
Chris Spencer
0dad9b1e76 [client] audio: fix latency calculation if audio device starts early
If the audio device starts earlier than required, we slew the read pointer
backwards to avoid underrunning. We need to apply this same offset to the
recorded device position, otherwise the Spice thread will think playback is
further ahead than it really is and inject unnecessary latency to
compensate.
2022-02-25 20:41:47 +11:00
Chris Spencer
a13c90bd27 [client] audio/pa: wait until stream is ready before starting playback
Uncorking the stream does not work if the stream is not ready yet.
2022-02-25 20:41:47 +11:00
Chris Spencer
84b5478b02 [client] audio/pa: fix assertion failure when keep alive playback stops
When the 'keep alive' playback times out, playback is stopped from the
audio callback, resulting in an assertion failure inside PulseAudio as we
try to lock the main loop thread while already inside it.
2022-02-25 20:41:47 +11:00
Tudor Brindus
91d6e3a82a [client] allow building with -Wstrict-prototypes
This is not yet turned on because cimgui does not build with it enabled.
2022-02-25 20:38:44 +11:00
Chris Spencer
d9dc399522 [client] audio/pw: request real-time priority
This is as per the PipeWire ALSA plugin [1]. The existing
`PW_STREAM_FLAG_RT_PROCESS` flag is misleading and doesn't really have
anything to do with real-time priority; it just tells PipeWire to pull data
from the application synchronously from its main processing thread. More
detail at [2].

[1] f5d47c079e/pipewire-alsa/alsa-plugins/pcm_pipewire.c
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2024
2022-02-14 15:11:43 +11:00
Chris Spencer
70158a64e7 [client] audio: open device earlier
The actual time between opening the device and the device starting to pull
data can range anywhere between nearly instant and hundreds of
milliseconds. To minimise startup latency, open the device as soon as the
first playback data is received from Spice. If the device starts earlier
than required, insert a period of silence at the beginning of playback to
avoid underrunning. If it starts later, just accept the higher latency and
let the adaptive resampling deal with it.
2022-02-14 15:09:13 +11:00
Geoffrey McRae
202116786c [client] main: fix invalid bit logic 2022-02-10 20:42:25 +11:00
Geoffrey McRae
8b4551c39c [all] convert KVMFR frame bools to flags in a bitfield
This will allow us to add additional flags in the future while remaining
backwards compatible with the host.
2022-02-10 20:32:38 +11:00
Geoffrey McRae
29698362ed [client] x11: added request activation support 2022-02-10 20:20:34 +11:00
Geoffrey McRae
f24db8d0cd Revert "[client] x11: check if the EWMH atoms exist before using them"
This reverts commit cfd2e6ff32.
2022-02-10 13:36:40 +11:00
Geoffrey McRae
cfd2e6ff32 [client] x11: check if the EWMH atoms exist before using them 2022-02-10 13:35:19 +11:00
Chris Spencer
e96311eb7b [client] audio: keep audio device open after playback
We can set the startup latency for the next playback far more precisely if
we have the device open already.

Only keep the device open with no playback for 30 seconds to avoid keeping
the device open unnecessarily forever.
2022-02-10 07:50:01 +11:00
Chris Spencer
0d97a51802 [client] audio: increase startup latency
Underruns can still happen quite easily at the beginning of playback,
particularly at very low latency settings. Further increase the startup
latency to avoid this.
2022-02-10 07:50:01 +11:00
Netboy3
e0c0451b52 [client] x11: Add inline icon
Many X11 window managers will present an application on their
taskbar as a combination of the application name and an icon
imagery pulled from the X-Property _NET_WM_ICON. Applications
built under frameworks such as Qt or GTK have this property
populated by the framework. This commit adds the Atom _NET_WM_ICON
and populates it with a 64x64 icon of Looking Glass.
2022-02-09 12:07:55 +11:00
Tudor Brindus
e1ac838796 [client] wayland: use wayland-protocols from submodule 2022-02-08 16:05:51 +11:00
Geoffrey McRae
1cfbcba813 [client] main: fix failure to check KVMFR udata at connect 2022-02-08 15:50:22 +11:00
Paul Hollinsky
3890c72159 [client] egl: use texture sampler for desktop
The desktop doesn't need its own sampler, there is already an identically
configured one in the `desktop->texture`.

For some reason, using the texture sampler fixes a black screen issue
with my GTX 660 using the 470.86 driver. Maybe hitting some limit
for how many samplers can be allocated?
2022-02-08 15:34:54 +11:00
Paul Hollinsky
4223a5e38f [client] egl: remove extra sampler from TextureBuffer
It was unused, there is a sampler in EGL_Texture (base).
2022-02-08 15:34:54 +11:00
Tudor Brindus
fd28d0604e [host/client] kvmfr: request activation based on guest state 2022-02-08 15:27:27 +11:00
Tudor Brindus
9cd8027901 [client] main: request WM activation on first frame 2022-02-08 14:54:55 +11:00
Tudor Brindus
969ac4d1d1 [client] wayland: activate our window if we're allowed 2022-02-08 14:54:55 +11:00
Tudor Brindus
da548e3858 [client] ds: expose activation requesting 2022-02-08 14:54:55 +11:00
Tudor Brindus
21a349343b [client] wayland: implement activation request 2022-02-08 14:54:55 +11:00
Tudor Brindus
4ee6bdf198 [client] wayland: bind xdg_activation_v1 when available 2022-02-08 14:54:55 +11:00
Tudor Brindus
b13582a911 [client] wayland: build xdg-activation-v1 header 2022-02-08 14:54:55 +11:00
Chris Spencer
05ca59ed48 [client] audio/pw: increase startup latency
PipeWire startup latency varies wildly depending on what else is, or was
last using the audio device. In the worst case, PipeWire can request two
full buffers within a very short period of time immediately at the start of
playback, so make sure we've got enough data in the buffer to support this.
2022-02-04 16:27:12 +11:00
Chris Spencer
e1e60fdaa6 [client] audio: tune target latency
The target latency is now based upon the device maximum period size
(which may be configured by setting the `PIPEWIRE_LATENCY` environment
variable if using PipeWire), with some allowance for timing jitter from
Spice and the audio device.

PipeWire can change the period size dynamically at any time which must be
taken into account when selecting the target latency to avoid underruns
when the period size is increased. This is explained in detail within the
commit body.
2022-02-04 16:27:12 +11:00
Chris Spencer
ca29fe80a6 Revert "[client] audio: tune the target latency based on the latency jitter"
This reverts commit febd081202.

This causes severe underruns when the quantum size increases.
2022-02-04 16:27:12 +11:00
Geoffrey McRae
febd081202 [client] audio: tune the target latency based on the latency jitter 2022-01-28 12:11:56 +11:00
Geoffrey McRae
5bbc1d44bf [client] audio/pw: get the period size to determine when to start audio
Previously this was hardcoded to 100ms which is far too high in most
instances, instead we get the initial period size and use whichever is
greater out of 50ms or the period size.

The idea is to reduce the amount of time it takes for the latency to
come down after initial stream start.
2022-01-28 12:08:58 +11:00
Geoffrey McRae
22b968ff53 [client] audio: change the audio latency graph sample point
This removes the need for locking while also giving a better result in
the graph output. Also when the graph is disabled via the overlay
options it will no longer cause redraws.
2022-01-28 10:59:12 +11:00
Geoffrey McRae
a0477466d2 Revert "[client] audio: allow the audiodev to return the periodFrames"
This reverts commit 41884bfcc5.

PipeWire can change it's period size on the fly on us making this
approach invalid.
2022-01-28 10:00:35 +11:00
Geoffrey McRae
c2a766c2ee [client] audio: fix setfault due to failure to properly reset 2022-01-27 19:20:16 +11:00
Geoffrey McRae
a560a610d9 [client] audio: allow building without any audio support 2022-01-27 18:03:11 +11:00
Geoffrey McRae
a7db3d3a0f [client] audio: check for malloc failure 2022-01-27 18:03:11 +11:00
Geoffrey McRae
016001da67 [client] audio: cosmetics 2022-01-27 18:03:11 +11:00
Geoffrey McRae
41884bfcc5 [client] audio: allow the audiodev to return the periodFrames
This change allows the audiodevs to return the minimum period frames
needed to start playback instead of having to rely on a pull to obtain
these details.

Additionally we are using this information to select an initial start
latency as well as to train the desired latency in order to keep it as
low as possible.
2022-01-27 18:03:11 +11:00
Chris Spencer
dd2d84a080 [client] audio: adjust playback speed to match audio device clock
This change is based on the techniques described in [1] and [2].

The input audio stream from Spice is not synchronised to the audio playback
device. While the input and output may be both nominally running at 48 kHz,
when compared against each other, they will differ by a tiny fraction of a
percent. Given enough time (typically on the order of a few hours), this
will result in the ring buffer becoming completely full or completely
empty. It will stay in this state permanently, periodically resulting in
glitches as the buffer repeatedly underruns or overruns.

To address this, adjust the speed of the received data to match the rate at
which it is being consumed by the audio device. This will result in a
slight pitch shift, but the changes should be small and smooth enough that
this is unnoticeable to the user.

The process works roughly as follows:
1. Every time audio data is received from Spice, or consumed by the audio
   device, sample the current time. These are fed into a pair of delay
   locked loops to produce smoothed approximations of the two clocks.
2. Compute the difference between the two clocks and compare this against
   the target latency to produce an error value. This error value will be
   quite stable during normal operation, but can change quite rapidly due
   to external factors, particularly at the start of playback. To smooth
   out any sudden changes in playback speed, which would be noticeable to
   the user, this value is also filtered through another delay locked loop.
3. Feed this error value into a PI controller to produce a ratio value.
   This is the target playback speed in order to bring the error value
   towards zero.
4. Resample the input audio using the computed ratio to apply the speed
   change. The output of the resampler is what is ultimately inserted into
   the ring buffer for consumption by the audio device.

Since this process targets a specific latency value, rather than simply
trying to rate match the input and output, it also has the effect of
'correcting' latency issues. If a high latency application (such as a media
player) is already running, the time between requesting the start of
playback and the audio device actually starting to consume samples can be
very high, easily in the hundreds of milliseconds. The changes here will
automatically adjust the playback speed over the course of a few minutes to
bring the latency back down to the target value.

[1] https://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
[2] https://kokkinizita.linuxaudio.org/papers/usingdll.pdf
2022-01-27 18:03:11 +11:00
Chris Spencer
599fdd6ffd [common] ringbuffer: add unbounded mode
In unbounded mode, the read and write pointers are free to move
independently of one another. This is useful where the input and output
streams are progressing at the same rate on average, and we want to keep
the latency stable in the event than an underrun or overrun occurs.

If an underrun occurs (i.e., there is not enough data in the buffer to
satisfy a read request), the missing values with be filled with zeros. When
the writer catches up, the same number of values will be skipped from the
input.

If an overrun occurs (i.e., there is not enough free space in the buffer to
satisfy a write request), excess values will be discarded. When the reader
catches up, the same number of values will be zeroed in the output.

Unbounded mode is currently unused since our audio input and output
streams are not synchronised. This will be implemented in a later commit.

Also reimplemented as a lock-free queue which is safer for use in audio
device callbacks.
2022-01-27 18:03:11 +11:00