From nobody Thu Jan 25 23:25:43 2024 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TLcQ02X3zz58GFj for ; Thu, 25 Jan 2024 23:25:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TLcPz6mWFz4nVG for ; Thu, 25 Jan 2024 23:25:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706225144; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v+rNJe0kTBFOvoAiq5lw7A/C5i/stnvooUB6k2PlOAg=; b=PniJnKWyll6//CcKJMBcWb4Ld0yPUv45CC3OFn+gapvr3NlIHc+4dP1FPV6pRRhrOXvMhY NN/fRMjCCGFgdXuDYh0I+wu6p+53wb0N6caLRD7Gq8kkvvgQlhpqds+3t6Zdvg4QukDLKd 3LpniKSI3akG8RpnBK/nIBaUSFjJKCU8ecYInahOBX7TgKKLoFACyKWjn+2+EDiKwAW8ER m4eWMG5GIa3h+iKsNwC3sa/X1ro8bmmh7Pr2jLE1g2OojdsG3fgJBvMlcIRNkcq6y+VhjQ M5Ek5KmSZbAeIcwXRZ5Xn1H2brv9rA5p1Y9IeoliukRClHybxNHxnNcxddKtIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706225144; a=rsa-sha256; cv=none; b=RyuCO2Ca8YVa8jW337IJ3HOznJYegKNiCMT6/HufxXMy0mQO333IbDHc5BrDWXRT0Bl9xW nwx0a+WyXlNfOW7yCVGtEWSiqYsk+GJZFRVMPHqtqXN3Y4OKMCZ0emOO3uOFCN6IYC29eS AVuRyHuA0n19X8qrTRBNcqECT1KOD+73df9XKOvy7oyRmIhIYHpE+xH80WEYIlJZkD/uYv yd4+pdSLPv+w1h+Jl29XSAzWtdyR4/QAaz/V9PIJZOM7ilYuMyQdhArVuNfSVAG1D2nvYG tDgXWM5sRZQKnajPLSEixQHV1oAsMA/yhIYAf0KkcTUz0pk0b6+QxJh7c76U1Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TLcPz5rNMzHhv for ; Thu, 25 Jan 2024 23:25:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40PNPh6Z077148 for ; Thu, 25 Jan 2024 23:25:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40PNPh0s077143 for ports-bugs@FreeBSD.org; Thu, 25 Jan 2024 23:25:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 276607] audio/jack: artifact noises, "Write buffer balancing", mixed rtprio Date: Thu, 25 Jan 2024 23:25:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dev@submerge.ch X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276607 --- Comment #1 from Florian Walpen --- One question first: Do you know about mac_priority(4)? Is there any reason = not to give the designated Jack user realtime privileges? I'm thinking about removing the whole rtprio hack from the RC service file. Which should be possible now that all supported versions of FreeBSD have the mac_priority module. Going realtime would then be: 1. Add designated Jack user to the realtime group. 2. Change "jackd_args" in rc.conf to use realtime mode ("-R ..."). Am I missing something? =3D=3D Context =3D=3D The default way to start Jack is now through the DBUS interface (jack_contr= ol), on demand. While I do not use the RC service anymore, I appreciate its usefulness and I'm willing to support it, as long as it works - against the recommendation of upstream. But both the Jack server and the whole Jack ecosystem are now built on the assumption that threads can gain (and drop) realtime priority independently= and by themself. Consequences are that - Not all threads of the Jack server and its clients _should_ have realtime priority - Threads will drop realtime priority and try to regain it later when need= ed I'm sure that having only Jack server started with realtime priority can ha= ve positive effects in certain scenarios (like yours). But without the clients getting realtime priority too, its usefulness is limited. And it leads to problems similar to bug #263373. That's why I'd like to get rid of the rtpr= io hack completely, in favor of the more consistent user realtime privilege. =3D=3D About Buffer Balancing =3D=3D The buffer balancing in Jack is an attempt to correct uneven progress betwe= en recording and playback channels. It does so by manipulating the playback channel, filling gaps or dropping samples. Please note that this can be both the cause or a symptom of the audible "knacks". And yes, sometimes it overreacts. The upcoming version of Jack will have a different approach. Apart from realtime priority, there's some other possible workarounds: - Start Jack without a recording device, if you don't need it - Drop CPU intensive workloads to lower priority (e.g. run poudriere with = idle priority) - Disable vchans and go bitperfect if Jack is the only consumer of the dev= ice - Go for smaller blocksize of the device (hw.snd.latency, hw.usb.uaudio.buffer_ms) - Make the Jack period a multiple of the blocksize (depends on your hardwa= re) --=20 You are receiving this mail because: You are the assignee for the bug.=