Hi Lexi,

On Thursday, February 22, 2024 2:45:07 AM CET Lexi Winter wrote:
> hello,
> 
> since the commit:
> 
> 42fdcd9fd917 snd_uaudio(4): Fix config detection with defaults set.
> 
> my snd_uaudio(4) no longer works.  the symptom is that applications
> attempting to play audio hang forever, and no audio is produced.
> reverting this commit fixed the problem.
> 
> the issue only occurs if i have this set in /boot/loader.conf:
> 
> hw.usb.uaudio.default_bits=32
> hw.usb.uaudio.default_rate=48000
> 
> removing these two settings makes audio work correctly again.

Thanks for reporting this. While I don't see the need to set these lines in 
loader.conf, at least not for your particular audio device, it certainly 
shouldn't break anything.

I think it might be helpful to handle this case in a PR on bugs.freebsd.org, 
if you don't mind? We probably need more info and logs.

> 
> my audio device:
> 
> ugen3.2: <Focusrite Scarlett 18i20 USB> at usbus3
> uaudio0 on uhub1
> uaudio0: <Focusrite Scarlett 18i20 USB, class 239/2, rev 2.00/6.6c, addr 1>
> on usbus3 uaudio0: Play[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 192000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 176400 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 96000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 88200 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 44100 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 192000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 176400 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 96000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 88200 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 44100 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: MIDI sequencer.
> pcm0 on uaudio0
> uaudio0: No HID volume keys found.

I have a Scarlett 18i20 myself, but maybe a different generation - it has 18 
recording channels as its name suggests. Is 20 recording channels correct for 
your device?

> 
> and /dev/sndstat:
> 
> FreeBSD Audio Driver (64bit 2009061500/amd64)
> Installed devices:
> pcm0: <Focusrite Scarlett 18i20 USB> on uaudio0 (1p:0v/1r:0v) default
>       snddev
> flags=0x3e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,BITPERFECT,VPC>
> [pcm0:play:dsp0.p0]: spd 48000, fmt 0x01401000, flags 0x2000110c,
> 0x00000001, pid 22326 (virtual_oss) interrupts 115908, underruns 0, feed
> 115907, ready 123440 [b:30720/15360/2|bs:131040/65520/2] channel
> flags=0x2000110c<RUNNING,TRIGGERED,BUSY,HAS_SIZE,BITPERFECT> {userland} ->
> feeder_root(0x01401000) -> {hardware}
>       [pcm0:record:dsp0.r0]: spd 48000, fmt 0x01401000, flags 0x2000112c,
> 0x00000001, pid 22326 (virtual_oss) interrupts 115930, overruns 97, feed
> 229796, hfree 30720, sfree 65440 [b:30720/15360/2|bs:65440/32720/2] channel
> flags=0x2000112c<RUNNING,TRIGGERED,SLEEPING,BUSY,HAS_SIZE,BITPERFECT>
> {hardware} -> feeder_root(0x01401000) -> {userland}
> Installed devices from userspace:
> dsp.full: <Virtual OSS> (play/rec)
> dsp.record: <Virtual OSS> (play/rec)
> dsp: <Virtual OSS> (play/rec)
> 
>       regards, lexi.

I see that there's a lot of recording overruns and the recording software side 
buffer of the pcm device is unusually small. Does recording work well for you?

Apart from that, I'd be interested in the exact circumstances this problem 
occurs. Could you provide the dmesg and sndstat output as above, but with the 
settings in loader.conf applied and playback hanging?

Since you're using virtual_oss, I suppose it produces an error log somewhere? 
And then maybe the output of the following commands, also while playback is 
hanging:

sysctl hw.snd
sysctl dev.pcm.0

You might also try to change the sample rate in virtual_oss to some other 
value, and then back to 48000. That could give us a hint.

Regards,

Florian




Reply via email to