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

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Dec 4 01:55:24 UTC 2020


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

--- Comment #42 from Florian Walpen <dev at submerge.ch> ---
Created attachment 220234
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=220234&action=edit
Handle non-power-of-2 sized buffers on the OSS side

Hi Goran, not there yet, but we're getting closer to "generally working"
territory. Could you test the above patch applied to your repo, both with 455
and standard periods like 512, and ignorehwbuf disabled?

Background (someone correct me if I'm wrong):
 * Fragment size (== block size) is always 2^N in FreeBSD (minus 3byte
rounding)
 * Fragment count is also a 2^N number
 * Some hardware requires odd jack2 periods to achieve 2^N buffer sizes (24bit,
18in18out)
 * Some hardware cannot achieve 2^N buffer sizes (10in12out)
 * Writes (reads) of exactly fragment size may be desirable, but not strictly
necessary
 * jack2 setting "ignorehwbuf" is not read from settings, always set to true

The current execution path with "ignorehwbuf" set handles non-2^N buffer sizes
by adjusting the jack2 period written per cycle, but fails to update the actual
buffer size - thus we write garbage to OSS in that case. Also the adjustment is
uncoordinated between in and out channels, fails completely for asymmetric
channel counts.

What this patch supposedly does:
 * Preserve current behavior for 2^N buffer sizes
 * Only adjust the jack2 period if "ignorehwbuf" is set (yes, funny name)
   * Update buffer size in that case
   * Asymmetric channel counts are still broken with "ignorehwbuf"
 * Otherwise allow non-2^N buffer sizes
   * Ignore fragment size for reads and writes in that case
   * Request more but smaller fragments (same total size)

Not sure about using smaller fragments, it seemed to help with jitter
tolerance, but I'm not totally convinced that the fragment size works like I
think it does.

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


More information about the freebsd-multimedia mailing list