Date: Fri, 04 Dec 2020 13:45:24 +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-NIHwn7NK8h@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 #45 from Florian Walpen <dev@submerge.ch> --- (In reply to Hans Petter Selasky from comment #43) Thanks for the hint. Reading the fragment size is not a problem, we do that, but requesting one that is e.g. a multiple of 512 * 4 * 18. If you know of = any way to do this, please tell me. If I follow the code path from the IOCTLs to chn_resizebuf(...) in sys/dev/sound/pcm/channel.c: > /* > * The application has requested their own blksz/blkcnt. > * Just obey with it, and let them toast alone. We can > * clamp it to the nearest latency profile, but that would > * defeat the purpose of having custom control. The least > * we can do is round it to the nearest ^2 and align it. > */ And the code around it looks accordingly, which is why I see no way to requ= est a fragment size that matches the period cycle from jack. Not if the channel count or the sample size are non-2^N. Even if jack cannot obtain a matching fragment size, it's still possible to write and read arbitrary chunks, e.g. 512 * 4 * 18 bytes. That's what my pa= tch is for. In that case my question is: How does the fragment size affect performance and timing tolerance? Are single fragments only processed when = they are full, or more continuously like the scatter / gather buffers in read(..= .) and write(...)? --=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-NIHwn7NK8h>