updated docs

Author: Tiramisioux

docs/acknowledgments.md

@@ -1,6 +1,6 @@
 # Acknowledgements
 
-The [**Cinemate**](https://github.com/Tiramisioux/cinemate) stack is built on top of several open-source projects. Special thanks to all authors!
+The [**Cinemate**](https://github.com/Tiramisioux/cinemate) stack is built on of several open-source projects. Special thanks to all authors!
 
 - [**CinePi-raw**](https://github.com/cinepi/cinepi-raw) – Csaba Nagy
 - [**IMX585 and IMX283 drivers**](https://github.com/will127534) – Will Whang

docs/audio-recording.md

@@ -1,60 +1,54 @@
 # Audio recording (experimental)
 
-Cinemate records audio alongside the image sequence. Support is currently limited to a few USB microphones with hard coded configurations:
+Cinemate records audio alongside the image sequence. Audio is written as `.wav` files into the same folder as the `.dng` frames. The implementation is still experimental and audio/video synchronization needs further investigation.
+
+## Supported microphones
  - **RØDE VideoMic NTG** – recorded in stereo at 24‑bit/48 kHz.
  - **USB PnP microphones** – recorded in mono at 16‑bit/48 kHz.
 
-Other class‑compliant USB microphones are now detected automatically by probing the ALSA hardware devices reported by `arecord -l`. Cinemate will fall back to using the matching USB device (via `plughw:<card>,<device>`) if the `mic_24bit` or `mic_16bit` aliases are not available.
-
-Audio is written as `.wav` files into the same folder as the `.dng` frames. The implementation is still experimental and audio/video synchronization needs further investigation.
-
-### .asoundrc Setup
 
-For `dsnoop` support, create a `~/.asoundrc` in home directory:
 
-```bash
-nano ~/.asoundrc
-```
+## .asoundrc Setup
 
-Paste this into the file:
+For `dsnoop` support, create a `~/etc/asound.conf`:
 
 ```bash
 
-    pcm.dsnoop_24bit {
-        type dsnoop
-        ipc_key 2048
-        slave {
-            pcm "hw:Device,0"
-            channels 2
-            rate 48000
-            format S24_3LE
-            period_size 1024
-            buffer_size 4096
-        }
-    }
-
-    pcm.dsnoop_16bit {
-        type dsnoop
-        ipc_key 2049
-        slave {
-            pcm "hw:Device,0"
-            channels 1
-            rate 48000
-            format S16_LE
-            period_size 1024
-            buffer_size 4096
-        }
-    }
-
-    pcm.mic_24bit {
-        type plug
-        slave.pcm "dsnoop_24bit"
-    }
-
-    pcm.mic_16bit {
-        type plug
-        slave.pcm "dsnoop_16bit"
-    }
+sudo tee /etc/asound.conf >/dev/null <<'EOF'
+# --- Hardware handle (use stable card name; change "NTG" if your card shows a different name in `arecord -l`)
+pcm.mic_hw {
+  type hw
+  card "NTG"
+  device 0
+}
+
+# --- One shared dsnoop backend pinned to the mic's native mode (RØDE NTG: S24_3LE @ 48k, stereo)
+pcm.mic_dsnoop {
+  type dsnoop
+  ipc_key 5978
+  ipc_perm 0666
+  ipc_key_add_uid false
+  slave {
+    pcm "hw:CARD=NTG,DEV=0"
+    format S24_3LE
+    rate 48000
+    channels 2
+  }
+  bindings.0 0
+  bindings.1 1
+}
+
+# --- Front-ends: let plug adapt whatever the app asks for (stereo 24-bit or mono 16-bit)
+pcm.mic_24bit {
+  type plug
+  slave.pcm "mic_dsnoop"
+}
+
+pcm.mic_16bit {
+  type plug
+  slave.pcm "mic_dsnoop"
+}
+EOF
 
 ```
 

docs/backing-up-sd-card.md

@@ -1,6 +1,6 @@
 # Backing up the SD card
 
-## To create a compressed image using PiShrink
+## Create a compressed image using PiShrink
 
 ```shell hl_lines="2 3"
 sudo bash -Eeuo pipefail -c '

docs/cinepi-multi.md

@@ -1,6 +1,6 @@
 # How Cinemate launches cinepi-raw
 
-`cinemate/src/module/cinepi_multi.py`  starts one `cinepi-raw` process per connected camera. It takes camera information `cinemate/src/module/sensor_detect.py` and user settings from `cinemate/src/module/settings.json` to build the command and command-line flags passed to `cinepi-raw`.
+The file `cinemate/src/module/cinepi_multi.py`  starts one `cinepi-raw` process per connected camera. It takes camera information `cinemate/src/module/sensor_detect.py` and user settings from `cinemate/src/module/settings.json` to build the command and command-line flags passed to `cinepi-raw`.
 
 
 ## Detecting Cameras

docs/cli-commands.md

@@ -13,9 +13,11 @@ corresponding controller methods.
      cinemate       # start cinemate manually
 
 !!! note ""
+     
      Commands without an explicit argument will toggle the current state when possible (e.g. `set fps lock` flips the lock; `set fps lock 1` forces it on).
 
 !!! note ""
+
      All of the commands below can be easily mapped to GPIO buttons rotary encoders and other input devices. See [this section](settings-json.md) for how to configure the settings file.
 
 

docs/cli-user-guide.md

@@ -1,7 +1,5 @@
 # Using CinePi-RAW from the terminal
 
-Here is how you can operate **CinePi-raw** from the command line. 
-
 ## Checking available options
 
 Before running the program you can view all command‑line flags with:
@@ -14,7 +12,7 @@ This prints a long list of options supported by the application. It includes the
 
 ## Camera modes
 
-CinePi-raw uses **Libcamera** to talk to your Raspberry Pi camera module. Each sensor supports one or more *modes*, which define the resolution and bit depth of the RAW images that the sensor can produce. A mode is written as:
+CinePi-Raw uses **Libcamera** to talk to your Raspberry Pi camera module. Each sensor supports one or more *modes*, which define the resolution and bit depth of the RAW images that the sensor can produce. A mode is written as:
 
 ```
 --mode 2028:1080:12:U

docs/compiling-cinepi-raw.md

@@ -1,7 +1,6 @@
 # Recompiling cinepi-raw
-Compiling cinepi-raw
 
-For easy later rebuilding and installation of cinepi-raw you can create the file compile-raw.sh.
+For easy later rebuilding and installation of cinepi-raw you can create the file `compile-raw.sh`.
 
 ```shell
 nano compile-raw.sh

docs/sensor.sizes.md

@@ -20,18 +20,18 @@ C and CS lenses were designed for small‑format video and security cameras, so
 
 ---
 
-## 4  What if I really want wide shots?
+## What if I really want wide shots?
 
 You have two realistic options:
 
 1. **Speed‑boosters and focal reducers**  
    These compress a larger image circle down onto the small sensor, regaining some angle of view. They cost more than the camera and introduce extra optical surfaces, but can work in a pinch.  
 2. **A bigger sensor**  
-   Stepping up to something like the IMX585 (“1/1.2 inch”) cuts the crop factor roughly in half. At that point, adapting Micro‑Four‑Thirds or vintage 35 mm lenses begins to make practical sense.
+   Stepping up to something like the IMX585 (“1/1.2 inch”) cuts the crop factor roughly in half. At that point, adapting Micro‑Four‑Thirds or vintage 35 mm lenses begins to make practical sense.
 
 ---
 
-## 5  Buying roadmap for beginners
+##  Buying tips for beginners
 
 1. **Start with the stock 6 – 12 mm Raspberry Pi zoom**  
    It teaches you which focal lengths you genuinely use.  

docs/storage-preroll.md

@@ -1,22 +1,23 @@
 # Storage pre-roll warm-up
 
-Cinemate includes an automatic "storage pre-roll" that records and discards a short clip to make sure new media can keep up before you roll on something important.【F:src/module/storage_preroll.py†L1-L57】 The warm-up runs the recorder at full speed so SSDs spin up, controllers cache their write tables and the rest of the pipeline has a chance to stabilise.
+Cinemate includes an automatic "storage pre-roll" that records and discards a short clip to make sure new media can keep up. The warm-up runs the recorder at full speed so SSDs spin up, controllers cache their write tables and the rest of the pipeline has a chance to stabilise.
 
 ## When the pre-roll runs
 
-- **On startup:** after a brief settle delay, the helper checks whether the RAW volume is mounted and triggers a warm-up run if so.【F:src/module/storage_preroll.py†L58-L96】
-- **Whenever storage mounts:** the SSD monitor emits an event that immediately schedules another pre-roll so freshly attached drives are exercised before you use them.【F:src/module/storage_preroll.py†L40-L92】
-- **On demand:** you can type `storage preroll` in the Cinemate CLI to queue a run manually. The command is ignored while a pre-roll is already active so repeated presses do not stack up.【F:src/module/cli_commands.py†L64-L72】【F:src/module/storage_preroll.py†L40-L92】
+- **On startup:** after a brief settle delay, the helper checks whether the RAW volume is mounted and triggers a warm-up run if so.
 
-The module keeps a lock so only one warm-up runs at a time and exposes the `storage_preroll_active` Redis key to let the UI show progress.【F:src/module/storage_preroll.py†L26-L74】
+- **Whenever storage mounts:** the SSD monitor emits an event that immediately schedules another pre-roll so freshly attached drives are exercised before you use them.
+
+- **On demand:** you can type `storage preroll` in the Cinemate CLI to queue a run manually. The command is ignored while a pre-roll is already active so repeated presses do not stack up.
+
+The module keeps a lock so only one warm-up runs at a time and exposes the `storage_preroll_active` Redis key to let the UI show progress.
 
 ## What happens during a run
 
-1. The helper aborts if no media is mounted or if a real recording is in progress; it will try again after the next trigger.【F:src/module/storage_preroll.py†L108-L133】
-2. It records the user's current FPS choice, switches the camera to the maximum FPS supported by the sensor/mode and raises a "pre-roll active" flag so other systems (such as the `rec` command) leave it alone.【F:src/module/storage_preroll.py†L134-L170】【F:src/module/cinepi_controller.py†L523-L542】
-3. Cinemate starts recording, waits until the REC flag is live, keeps rolling for the configured duration (two seconds by default) and then stops once all file buffers have flushed to disk.【F:src/module/storage_preroll.py†L134-L170】
-4. Finally, it restores the previous FPS, clears the activity flag and deletes any temporary clip directories created during the warm-up so the test footage never clutters your drive.【F:src/module/storage_preroll.py†L170-L208】
+1. The helper aborts if no media is mounted or if a real recording is in progress; it will try again after the next trigger.
+
+2. It records the user's current FPS choice, switches the camera to the maximum FPS supported by the sensor/mode and raises a "pre-roll active" flag so other systems (such as the `rec` command) leave it alone.
 
-## Why it matters
+3. Cinemate starts recording, waits until the REC flag is live, keeps rolling for the configured duration (two seconds by default) and then stops once all file buffers have flushed to disk.
 
-Running a quick high-FPS burst before your first take helps avoid storage hiccups (for example, when an SSD controller is still negotiating link speed or establishing its allocation tables). Because Cinemate blocks normal `rec` requests while a pre-roll is active, you will always start your real recording on a fresh, warmed-up drive.【F:src/module/storage_preroll.py†L134-L208】【F:src/module/cinepi_controller.py†L523-L542】 Trigger it manually after swapping drives or when you have not recorded for a while to ensure peak performance.
+4. After recording the 2 second temporary clip, it restores the previous FPS, clears the activity flag and deletes the temporary clip directory.

docs/system-services.md

@@ -4,7 +4,7 @@ Cinemate uses three system services for its operation.
 
 ## cinemate-autostart.service
 
-Responsible for autostart of Cinemate on boot. By default, it is turned off on the [downloadable image file](https://github.com/Tiramisioux/cinemate/releases/tag/3.1).
+Responsible for autostart of Cinemate on boot. By default, it is turned off on the [downloadable image file](https://github.com/Tiramisioux/cinemate/releases/tag/3.2).
 
 Starting in v3.2 the service now waits for the camera sensor to come online before launching the UI. The helper script `/usr/local/bin/camera-ready.sh` polls `cinepi-raw --list-cameras` for up to 30 seconds and logs progress to the systemd journal so Cinemate does not start with a black screen if the IMX sensor is still initialising.