Date: Fri, 04 Dec 2020 15:17:34 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 251125] audio/jack: update to jack2 or add new port audio/jack2 Message-ID: <bug-251125-12827-L7UT3QKYOS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251125-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-251125-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251125 --- Comment #48 from Florian Walpen <dev@submerge.ch> --- (In reply to Hans Petter Selasky from comment #46) > There is: > > SNDCTL_DSP_SETBLKSIZE I've seen that in the FreeBSD sources, but it sets fragment count to 2 and ends up in the same chn_resizebuf(...) as above, rounding fragment size to 2^N and then aligns it to frame size. I'm not using Virtual OSS unfortunately, but Goran does, I think - it may be worth a try as Virtual OSS seems to be more flexible in this regard. But this IOCTL is specific to FreeBSD and Virtual OSS I think. > A fragment is usually the smallest entity the audio driver can process. With > USB audio this entity is fixed and can be slightly controlled by > hw.usb.uaudio.buffer_ms to 2,3,4,5,6,7 or 8 ms. In that case it would be best to leave the predefined fragment size as is, right? But we'd have to make sure that jack doesn't block for too long, there must be enough fragments to hold the jack period (twice). I have to check this. > Other drivers select the buffer size given by the user. This also depends on > the use of vchans. Bitperfect mode is different, as you know. I suppose we should set the fragment size there. A strategy could be to divide the total buffer size into 8 fragments for longer period cycles, and 4 fragments for short periods, if there is no matching fragment size. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251125-12827-L7UT3QKYOS>