[Bug 295933] uaudio(4): idle capture stream clobbers active playback sample rate on devices with a shared UAC2 Clock Source - device unusable

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D295933

--- Comment #15 from [email protected] ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3D755685dd665ef209912c59da6a7d0e7f2=
c9f464b

commit 755685dd665ef209912c59da6a7d0e7f2c9f464b
Author:     giacomo <[email protected]>
AuthorDate: 2026-07-15 11:34:34 +0000
Commit:     Christos Margiolis <[email protected]>
CommitDate: 2026-07-24 11:20:08 +0000

    snd_uaudio: Don't let an idle stream reprogram a shared UAC2 clock

    Some UAC2 devices expose a single Clock Source entity that is shared
    between their playback and capture interfaces (it appears in both the
    output and input clock bitmaps).  On such a device uaudio(4) programs
    the sample rate for both directions when a stream starts.  If playback
    runs at a 44.1 kHz-family rate while the idle capture channel is left
    at its 48 kHz-family default, the capture
    SET_CUR(UA20_CS_SAM_FREQ_CONTROL) is issued after the playback one and
    overwrites the rate on the shared clock.  The device then runs at
    ~48 kHz while the playback stream carries 44.1 kHz data.  Consuming
    samples faster than they arrive, the device repeatedly runs out of
    data, loses sync with the playback stream, and re-locks onto it
    (audible dropouts, front-panel play/idle flicker).  The 48 kHz family
    is unaffected because both directions then agree on the rate.

    Fix it in three parts:

    - Add a shared-clock guard: before issuing SET_CUR to a clock id, if
      that clock is shared between playback and capture and the other
      direction is already streaming at a different rate, skip it.  The
      first active stream owns the clock; a later one follows it.

    - When the recording channel is auto-started only as a source of jitter
      information for asynchronous playback, align its nominal rate to the
      playback rate before starting it, so it neither reprograms the shared
      clock to a conflicting rate nor produces mismatched frame sizes.

    - Always submit the explicit-feedback SYNC transfer so
      dev.pcm.%d.feedback_rate stays live as a diagnostic even when a
      capture stream is present.

    Reproduced on an OKTO RESEARCH DAC8 STEREO (0x152a:0x88c5), whose
    vestigial capture interface never streams; the same device plays the
    44.1 kHz family correctly under Linux's snd-usb-audio.

    As a side effect, this patch also fixes the sample rate bug mentioned in
    the BUGS section of sound(4)'s man page, where a device needs to have
    the same sample rate set for both playback and recording in order to
    work properly.

    PR:             295933
    Assisted-By:    Claude Opus 4.8 (claude-opus-4-8)
    Signed-off-by:  giacomo <[email protected]>
    MFC after:      2 weeks
    Reviewed by:    christos
    Pull-Request:   https://github.com/freebsd/freebsd-src/pull/2323

 sys/dev/sound/usb/uaudio.c | 103 +++++++++++++++++++++++++++++++++++++++++=
----
 1 file changed, 95 insertions(+), 8 deletions(-)

--=20
You are receiving this mail because:
You are the assignee for the bug.=