From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7DFD6158074 for ; Tue, 24 Jun 2025 05:46:58 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 37406341435 for ; Tue, 24 Jun 2025 05:46:58 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 4F36D110554; Tue, 24 Jun 2025 05:46:53 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 46303110554 for ; Tue, 24 Jun 2025 05:46:52 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (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) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8AFCD340DAF for ; Tue, 24 Jun 2025 05:46:52 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id E9C612A05 for ; Tue, 24 Jun 2025 05:46:50 +0000 (UTC) From: "Alexander Tsoy" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Alexander Tsoy" Message-ID: <1750743730.c7bdb9d8c04569087f98adad5c25194086e92e9e.alexander@gentoo> Subject: [gentoo-commits] repo/proj/guru:dev commit in: media-sound/zita-ajbridge/ X-VCS-Repository: repo/proj/guru X-VCS-Files: media-sound/zita-ajbridge/metadata.xml X-VCS-Directories: media-sound/zita-ajbridge/ X-VCS-Committer: alexander X-VCS-Committer-Name: Alexander Tsoy X-VCS-Revision: c7bdb9d8c04569087f98adad5c25194086e92e9e X-VCS-Branch: dev Date: Tue, 24 Jun 2025 05:46:50 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: e6c10cbd-a501-436a-8420-b8a04514488b X-Archives-Hash: ecd476dbb894ca56d9d86a5999949df6 commit: c7bdb9d8c04569087f98adad5c25194086e92e9e Author: Alexander Tsoy tsoy me> AuthorDate: Tue Jun 24 05:28:08 2025 +0000 Commit: Alexander Tsoy tsoy me> CommitDate: Tue Jun 24 05:42:10 2025 +0000 URL: https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=c7bdb9d8 media-sound/zita-ajbridge: shorten longdescription Signed-off-by: Alexander Tsoy tsoy.me> media-sound/zita-ajbridge/metadata.xml | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/media-sound/zita-ajbridge/metadata.xml b/media-sound/zita-ajbridge/metadata.xml index b9f76961cc..7df5d07ee9 100644 --- a/media-sound/zita-ajbridge/metadata.xml +++ b/media-sound/zita-ajbridge/metadata.xml @@ -2,22 +2,14 @@ - Zita-ajbridge provides two applications, zita-a2j and zita-j2a. They allow to use an ALSA device as a Jack client, to provide additional capture (a2j) or playback (j2a) channels. Functionally these are equivalent to the alsa_in and alsa_out clients that come with Jack, but they provide much better audio quality. The resampling ratio will typically be stable within 1 PPM and change only very smoothly. Delay will be stable as well even under worse case conditions, e.g. the Jack client running near the end of the cycle. - -The theory of operation and internals of these apps are the subject of a paper presented at LAC 2012. - -The alsa device should be a 'hw:' one, i.e. direct access to a soundcard and not an ALSA 'plug' device. A well-working Jack system is assumed, running in real-time mode. - -The sample rate can be the same as Jack's one, or different. Minimum delay is obtained by running the alsa device at a lower period size than Jack. This can be done safely as the alsa thread will run at a higher priority, and apart from copying to/from an internal buffer no work is done there. There are no restrictions on the product of period_size and number_of_periods as there are for alsa_in and alsa_out. - -Both apps will optionally (-v option) print some information four times per second. The first number is the average loop error over the last quarter second, in samples. It should be reduced to small randowm values close to zero after 15 seconds or so. The second is the dynamic correction factor of the nominal resampling ratio. This should converge to a value close to one and not move much. You may observe small variations in these numbers when Jack apps are started or stopped. This is normal. Anything else isn't - please report. - -The same -v option will enable detailed error reporting from the ALSA interface, or if all is OK print a summary of the ALSA device configuration. - -The -L option forces the ALSA device to 2 channels and 16-bit sample format. This can be required when using the ALSA loop device if the other side (e.g. mplayer) does not support more channels or a floating point sample format. This will fail on real hw: devices as these can be opened in mmap mode only with their real number of channels. - -When starting, and in case of major trouble, you will see the 'Starting synchronisation' message. This can happen if there is a timeout on the Jack server, e.g. a client crashed or terminated in a dirty way. Jack1 will skip one or more cycles when new apps are started, or when a large number of port connections is done in a short time. This may interrupt the audio signal, but should otherwise not have any ill consequences nor require a restart. - -Both apps will suspend operation while Jack is in 'freewheeling' mode. When using Jack1, returning from freewheeling to normal mode may generate large timing errors, the result of Jack's DLL not being re-initialised properly. Both apps will wait for 15 seconds before restarting if that happens. Patches to Jack1 have been submitted, so this problem should go away in the future. + + Zita-ajbridge provides two applications, zita-a2j and zita-j2a. They + allow to use an ALSA device as a Jack client, to provide additional + capture (a2j) or playback (j2a) channels. Functionally these are + equivalent to the alsa_in and alsa_out clients that come with Jack, + but they provide much better audio quality. The resampling ratio will + typically be stable within 1 PPM and change only very smoothly. Delay + will be stable as well even under worse case conditions, e.g. the Jack + client running near the end of the cycle.