Re: 42fdcd9fd917 broke my snd_uaudio(4)

Hi Lexi,

On Thursday, February 22, 2024 6:47:26 PM CET Lexi Winter wrote:
> hi Florian,
> 
> Florian Walpen:
> > 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?
> 
> this is a 3rd generation 18i20; as well the usual physical inputs it has
> a stereo loopback channel that can be configured in the built-in mixer
> and which appears as an additional two recording channels.  i think
> (although i'm not certain) that loopback functionality is new in the 3rd
> generation model.

That makes sense, I have the previous generation with no loopback channels.

> > > 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)
> > 
> > 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?
> i haven't had a chance to test recording yet beyond a single work
> conference call, as i've only just got playback working well (that
> required a lot of fiddling with various options until i settled on
> virtual_oss).

Yes, virtual_oss is currently the best option to break up multi-channel 
interfaces into smaller pcm devices, for general use.

> 
> if you can suggset any obvious changes i'd appreciate that - maybe it's
> just a case of increasing the virtual_oss buffer?  i did have to
> increase the playback buffer a bit as the virtual_oss default is rather
> small.

That was more like a general remark referring to this part of sndstat:
[b:30720/15360/2|bs:65440/32720/2]
The bs values show the buffer size of the pcm device, where the application 
(here virtual_oss) reads from. I just skimmed the source code, virtual_oss 
does set this buffer size according to its own buffer size. Here the buffer 
can hold 818 samples (~17ms), and the virtual_oss buffer should fit in there 
twice. As I recommend a multiple of the sound card period (4ms, from dmesg), 
I'd guess 384 (8ms) would make a good setting for the virtual_oss buffer 
parameter here.
Maybe you can post your virtual_oss settings in the PR too.

> 
> > 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
> 
> i'll open a bug with this and the other details once i get a chance to
> reboot again to test, probably later today.

Perfect, thank you. I have some ideas already, we'll see.

Regards

Florian