Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
T
Tidal
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • PLN
  • Tidal
  • Repository

Switch branch/tag
  • Tidal
  • tools
  • latency-lens.py
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    fix(audio): wireplumber start-limit takes all audio out, and the doctor could not see it · 9edfd743
    PLN: 'media keys dont work' + 'tried bluetooth headset couldnt get sound there'.
    Cause was neither:
    
        wireplumber        failed (start-limit-hit)
        Sinks:  100. Dummy Output      <- the ONLY sink
        0 bluez objects
    
    pipewire is the graph; wireplumber is the session manager that puts DEVICES in
    it. Without it there are no device nodes at all -- every hardware sink vanishes,
    PipeWire invents Dummy Output, media keys act on nothing, and a Bluetooth
    headset cannot appear however well it pairs. It reads exactly like dead
    hardware.
    
    The trap is StartLimitBurst=5 / 5min with Restart=on-failure. Five hand-issued
    restarts inside two minutes exhausted it, and from then on restarting AGAIN
    cannot work. Cure is reset-failed, then start. Third instance of this exact
    shape in one session after parvagues-sc twice: on this box, 'X will not start'
    means check reset-failed first.
    
    rig-doctor's check_pipewire tested pipewire on PATH, pw-jack on PATH, and
    pipewire.service is-active -- and pipewire.service was ACTIVE for the whole
    outage, so the check was green while the box had no audio at all. Presence
    versus function again. It now also asserts wireplumber is active and that the
    graph holds at least one real output (alsa_output/bluez_output, never
    auto_null/Dummy), FAILs with the reset-failed cure in the fix field, and WARNs
    on a dummy or unset default. It caught a live regression the first time it ran.
    
    The headset itself was only MUTED: bluez_card active profile was already
    a2dp-sink, and the sink read '[vol: 0.20 MUTED]' -- per-device state wireplumber
    persists. Unmuted by NAME, because the BT node id moves between calls while the
    device reconnects. Not caused by the quantum/mute testing, which ran at 00:10
    with no BT device connected and left force-quantum verified at 0.
    
    latency-lens --print-config used to hand over 'systemctl --user restart pipewire
    pipewire-pulse wireplumber' with no warning, which repeated is precisely this
    trap. It now says ONCE, states the consequence, gives the cure, and points at
    the runtime setting that needs no restart.
    
    Doctor: 48 checks, 0 fail, 10 warn, 38 pass.
    PLN (Algolia) authored Sep 07, 2026
    9edfd743
latency-lens.py 20.7 KB
EditWeb IDE
×

Replace latency-lens.py

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.