fix(linux): add delay to service and improve troubleshooting docs (#2903)

Co-authored-by: ReenigneArcher <42013603+ReenigneArcher@users.noreply.github.com>

docs/source/troubleshooting/linux.rst

@@ -50,22 +50,26 @@ often grub is used to load the kernel and set its command line.)
 
 AMD encoding latency issues
 ---------------------------
-If you notice unexpectedly high encoding latencies (e.g. in Moolight's
+If you notice unexpectedly high encoding latencies (e.g. in Moonlight's
 performance overlay) or strong fluctuations thereof, this is due to
 `missing support <https://gitlab.freedesktop.org/drm/amd/-/issues/3336>`_
 in Mesa/libva for AMD's low latency encoder mode. This is particularly
 problematic at higher resolutions (4K).
 
-As of now this can only be fixed by recompiling Mesa with a test patch (see
-url above) that unconditionally enables a low latency tuning mode for all
-encoder workloads. This is for advanced users only and neither support nor
-warranty are provided. Note also that this patch entails a higher power
-consumption while encoding and may not be suitable for all use cases.
+Only the most recent development versions of mesa include support for this
+low-latency mode. It will be included in Mesa-24.2.
 
-(A crude workaround is to *increase* the load on the de-/encoder by having it
-de- or encode an additional arbitrary video stream in the background. This
-ensures that the encoder's clock frequencies stay high and the latency
-fluctuations disappear.)
+In order to enable it, Sunshine has to be started with a special environment
+variable:
+
+.. code-block:: bash
+
+   AMD_DEBUG=lowlatencyenc sunshine
+
+To check whether low-latency mode is being used, one can watch the ``VCLK`` and
+``DCLK`` frequencies in ``amdgpu_top``. Without this encoder tuning both clock
+frequencies will fluctuate strongly, whereas with active low-latency encoding
+they will stay high as long as the encoder is used.
 
 Gamescope compatibility
 -----------------------