Skip site navigation (1)Skip section navigation (2)
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=3D251125

--- Comment #48 from Florian Walpen <dev@submerge.ch> ---
(In reply to Hans Petter Selasky from comment #46)

> There is:
>=20
> 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 a=
nd
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 th=
is
IOCTL is specific to FreeBSD and Virtual OSS I think.

> A fragment is usually the smallest entity the audio driver can process. W=
ith
> 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, the=
re
must be enough fragments to hold the jack period (twice). I have to check t=
his.

> 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 div=
ide
the total buffer size into 8 fragments for longer period cycles, and 4
fragments for short periods, if there is no matching fragment size.

--=20
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>