[Bug 251125] audio/jack: update to jack2 or add new port audio/jack2

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251125

--- Comment #45 from Florian Walpen <dev at 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 request
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 patch
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(...)?

-- 
You are receiving this mail because:
You are the assignee for the bug.