https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295933
--- Comment #5 from [email protected] --- Thanks Christos — I tested both suggestions. Short version: both make the device lock at 44.1 kHz with no flicker. (1) sndctl play.rate=44100 rec.rate=44100 (comment #3) This is only settable outside bitperfect: with bitperfect on, vchans are 0 so play.rate/rec.rate write dev.pcm.0.{play,rec}.vchanrate, which don't exist / aren't writable. So I enabled vchans and disabled bitperfect, then as root: # sysctl dev.pcm.0.play.vchans=1 # sysctl dev.pcm.0.rec.vchans=1 # sndctl play.rate=44100 rec.rate=44100 (vchanrate is root-only, and rec needs its own vchan or the rec half EPERMs.) Result: locks at 44.1 kHz, stable, no flicker. (2) bitperfect + hw.usb.uaudio.default_rate=44100 (comment #4) # sysctl hw.usb.uaudio.default_rate=44100 then power-cycled the DAC so uaudio re-reads it at attach (setting it on an already-attached device had no effect on its own). Result: locks at 44.1 kHz, stable, no flicker; play.rate and rec.rate both read 44100. Interpretation: The DAC8 STEREO (0x152a:0x88c5) exposes a single UAC2 Clock Source shared between the playback (AS interface 1) and the capture (AS interface 2) interfaces. The 44.1 kHz-family flicker comes from the idle capture side defaulting to 48 kHz and reprogramming that shared clock out from under the active 44.1 kHz playback stream. Both workarounds remove the conflict simply by making the capture side use the same 44.1 kHz rate, so nothing reprograms the clock. This is consistent with our earlier finding that dropping the (vestigial — the DAC8 has no analog inputs) capture interface also fixes it. Related observation (format rather than rate): In bitperfect at 44.1 kHz a 16-bit source is shown by the DAC as 24-bit. uaudio exposes only s32le for playback (play.formats: s32le), although AS interface 1 declares native 16- and 24-bit alt-settings (FORMAT_TYPE_I): Alt1: subslot 4 / 24-bit Alt2: subslot 2 / 16-bit Alt3,4: subslot 4 / 32-bit Linux snd-usb-audio switches alt-setting per stream and shows 16-bit for 16-bit content. (hw.usb.uaudio.default_bits forces a depth, but it's a global, attach-time choice.) I mention it because it looks like the same underlying behaviour: uaudio fixes one (rate, bits) at attach instead of following the active stream / the shared clock. Happy to test patches or provide the full descriptor dump and debug traces. -- You are receiving this mail because: You are the assignee for the bug.
