Created attachment 200715 [details] Round up internal buffer sizes to make buffer offsets 16 byte aligned. When starting jackd on an OSS device with 24 bit sample resolution, jackd may just crash with SIGBUS as soon as it is exercised by some client like ardour. How to reproduce: 1. Install audio/jack and audio/ardour5 with default options (DYNSIMD=on) on a machine that supports SSE instructions. 2. Make sure the OSS device processes 24 bit samples, e.g. using vchan set sysctl dev.pcm.2.play.vchanformat=s24le:2.0 sysctl dev.pcm.2.rec.vchanformat=s24le:2.0 3. Start jackd with 24 bit samples on that OSS device, e.g. jackd -r -doss -r44100 -p1024 -n3 -w24 --capture /dev/dsp2 --playback /dev/dsp2 4. Create a new recording project in ardour5, jackd should crash as soon as the jack busses are initialized by Ardour. Workaround: Compile audio/jack with port option DYNSIMD disabled (DYNSIMD=off). Analysis: The jackd server crashes in x86_sse_copyf(...) found in libjack/simd.c, where it tries to process a misaligned buffer with SIMD instructions. These instructions require the buffer to be 16-byte aligned, which it is not. As far as I understand, the OSS part of jackd will reset the internal buffer size according to the number of samples that fit into the system device buffer. A standard system buffer of 8kB then contains 8192 bytes / 2 channels / 3 bytes per sample = 1365 samples. The jackd internal 4-byte float sample buffers will then be reset to size 1365 * 4 = 5460 which is not 16-byte aligned. For testing, this procedure and the buffer sizes are printed when starting jackd in verbose mode (-v). 16 bit and 32 bit samples on the OSS side usually do not exhibit this bug, because they tend to result in a number of buffered samples that is a multiple of 4. This may depend on buffer size and number of channels though. Patch: The patch provided can be added to audio/jack/files/ and inserts some padding to the internal buffers of the jack server to make them 16-byte aligned. It should only affect cases of misaligned buffer sizes when SIMD instructions are enabled.
Is there an upstream reference?
(In reply to Hans Petter Selasky from comment #1) Not yet, the upstream git repo didn't seem very active and I wanted to ask here first to rule out any basic misunderstanding regarding the OSS backend. But I will certainly try to push this upstream if you think it's legit. Also, I didn't search the jack2 repo for similar issues yet, only jack1.
Thank you for the report, analysis and patch Florian.
Thank you for the extensive investigation and the patch for this issue. It looks good to me, I'll commit it to our ports tree. Florian, could you get in touch with upstream and see that it makes its way into the upstream repository?
A commit references this bug: Author: riggs Date: Thu Jan 3 20:24:31 UTC 2019 New revision: 489219 URL: https://svnweb.freebsd.org/changeset/ports/489219 Log: Fix SIGBUS with 24 bit content over OSS output PR: 234574 Submitted by: dev@submerge.ch MFH: 2019Q1 Changes: head/audio/jack/Makefile head/audio/jack/files/patch-libjack_port.c
A commit references this bug: Author: riggs Date: Thu Jan 3 20:27:09 UTC 2019 New revision: 489220 URL: https://svnweb.freebsd.org/changeset/ports/489220 Log: MFH: r489219 Fix SIGBUS with 24 bit content over OSS output PR: 234574 Submitted by: dev@submerge.ch Approved by: ports-secteam (riggs) Changes: _U branches/2019Q1/ branches/2019Q1/audio/jack/Makefile branches/2019Q1/audio/jack/files/patch-libjack_port.c
(In reply to Thomas Zander from comment #4) Very nice, thank you! I will contact upstream tomorrow and post an update as soon as I have news.
FYI, the upstream pull request can be found at https://github.com/jackaudio/jack1/pull/83 and has the attention of the maintainer, but is not merged yet.