Date: Sun, 29 Nov 2020 16:08:09 +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-HEwAo9UQYV@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 #31 from Florian Walpen <dev@submerge.ch> --- (In reply to Goran Meki=C4=87 from comment #27) Not sure I can follow your intentions with buffer size calculations. You om= it sample size and channel count from the fragment size calculation: > gFragFormat =3D (fCaptureChannels << 16) + int2pow2(fEngineControl->fBuff= erSize); You will get a much too small block size (fInputBufferSize) and recalculate= the internal number of frames (fEngineControl->fBufferSize) from that: > int new_buffer_size =3D fInputBufferSize / (fSampleSize * fCaptureChannel= s); And then you repeat the whole thing for the output buffers, resulting in an even tinier fragment size and internal number of frames. This is completely unusable and inconsistent for my setup. Why not just set a smaller number of internal frames ("period") from the st= art, and then fit the fragment size to that like it was? We are writing the whole data in one go anyway, AFAICT. Or what are you trying to achieve? --=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-HEwAo9UQYV>