The pad speaker's path byte was pinned on a ~5x sweep, and the on-glass numbers are ~300x #281

Merged

enricobuehler merged 1 commits from worktree-ds5-speaker-enable into main 2026-08-17 11:19:25 +00:00

Conversation 0 Commits 1 Files Changed 1

+29 -4

enricobuehler commented 2026-08-17 11:15:58 +00:00

Owner

Copy Link

Copy Source

Comment only — no behaviour change.

speaker_enable_packet's 0x20 was chosen from a sweep that only cleared the pad-mic noise floor by ~5x, and the comment recorded the value as unsettled, pending confirmation by ear. It is now settled.

A second sweep on glass (2026-08-17, DS5 wired to a Steam Deck client streaming from a Bazzite host, 330 Hz driven into the speaker pair, the pad's own microphone as detector) swept the whole byte:

ucAudioEnableBits	330 Hz energy
0x00 (power-on)	0.000001	silent — the headphone jack
0x10	0.000002	silent
0x20	0.000283	speaker sounds
0x30	0.000336	speaker sounds, marginally louder
0x40	0.000001	silent
0x50	0.000002	silent

So bit 5 is the speaker-path enable and bit 4 alone does nothing — a ~300x margin rather than ~5x.

0x20 stays the default over the marginally louder 0x30, and the comment now says why: 0x30 asserts a second path bit whose effect on the headphone leg was never measured, and 0x20 already sounds. A pad with headphones in its jack must not lose them to a default.

Two properties this one-shot depends on were measured the same day and are now recorded, because neither was obvious:

• the setting persists — unchanged 40 s after a single write, with SDL live on the pad;
• it survives the pad's USB audio stream stopping and restarting, so it needs no re-assertion when the renderer opens its output (which happens lazily, minutes after slot open).

Verified end-to-end: forcing the pad to 0x00 dropped the pad mic to the 0.000000 floor and silenced the speaker; a fresh slot open restored it (0.000349, and audible). That also confirms the packet alone is what makes the speaker work.

Comment only — no behaviour change. `speaker_enable_packet`'s `0x20` was chosen from a sweep that only cleared the pad-mic noise floor by ~5x, and the comment recorded the value as unsettled, pending confirmation by ear. It is now settled. A second sweep on glass (2026-08-17, DS5 wired to a Steam Deck client streaming from a Bazzite host, 330 Hz driven into the speaker pair, the pad's own microphone as detector) swept the whole byte: | `ucAudioEnableBits` | 330 Hz energy | | |---|---|---| | `0x00` (power-on) | 0.000001 | silent — the headphone jack | | `0x10` | 0.000002 | silent | | `0x20` | 0.000283 | speaker sounds | | `0x30` | 0.000336 | speaker sounds, marginally louder | | `0x40` | 0.000001 | silent | | `0x50` | 0.000002 | silent | So **bit 5 is the speaker-path enable** and bit 4 alone does nothing — a ~300x margin rather than ~5x. `0x20` stays the default over the marginally louder `0x30`, and the comment now says why: `0x30` asserts a second path bit whose effect on the *headphone* leg was never measured, and `0x20` already sounds. A pad with headphones in its jack must not lose them to a default. Two properties this one-shot depends on were measured the same day and are now recorded, because neither was obvious: - the setting **persists** — unchanged 40 s after a single write, with SDL live on the pad; - it **survives the pad's USB audio stream stopping and restarting**, so it needs no re-assertion when the renderer opens its output (which happens lazily, minutes after slot open). Verified end-to-end: forcing the pad to `0x00` dropped the pad mic to the 0.000000 floor and silenced the speaker; a fresh slot open restored it (0.000349, and audible). That also confirms the packet alone is what makes the speaker work.

enricobuehler added 1 commit 2026-08-17 11:16:02 +00:00

docs(client): the pad speaker's path byte was pinned on a ~5x sweep, and the on-glass numbers are ~300x ... 08f154be07

speaker_enable_packet's 0x20 was chosen from a sweep that only cleared the pad-mic noise floor by ~5x, and the value was left recorded as unsettled. A second sweep on glass (DS5 wired to a Steam Deck client, 330 Hz into the speaker pair) swept the whole byte: 0x20 and 0x30 sound, 0x10/0x40/0x50 do not, and the margin is ~300x rather than ~5x. So bit 5 is the speaker-path enable and bit 4 alone does nothing.

Also records why 0x20 stays the default over the marginally louder 0x30 (0x30 asserts a second path bit whose effect on the headphone leg was never measured), and two properties this one-shot depends on that were measured the same day: the setting persists (unchanged 40 s after a single write, SDL live on the pad) and survives the pad's USB audio stream stopping and restarting, so it needs no re-assertion when the renderer opens its output.

Verified end-to-end: forcing the pad to 0x00 dropped the pad mic to the 0.000000 floor and silenced the speaker; a fresh slot open restored it (0.000349, audible). Comment only - no behaviour change.

enricobuehler merged commit 3c53f484fc into main 2026-08-17 11:19:25 +00:00

enricobuehler deleted branch worktree-ds5-speaker-enable 2026-08-17 11:19:33 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX HitFrostbite enricobuehler (Enrico Bühler) kszlim luxus nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#281