[arch-proaudio] Jami: is JACK implemented?
Hi, sorry if this is not the place to ask. I've been trying Jami for video-calls between a couple of laptops with Arch and Debian Testing. I've seen that in Arch one can choose JACK as audio server, which is *awesome*. But when tried to connect its ports (in the 'Connections' window of qjackctl) I'd found myself unable to. Is this how it's supposed to be working right now? I mean: is JACK implemented/usable, at what extent? Or what should I do to use Jami over JACK instead of PulseAudio?, without PA-bridge, just simple plain JACK. Thanks a lot in advance for any info. Best regards!
Hi riveravaldez, I'm not sure either if this belongs to this list, but since it's been quite calm in recent times, I try to provide a complet e answer. Am 11.02.21 um 10:43 schrieb riveravaldez via arch-proaudio:
Hi, sorry if this is not the place to ask.
I've been trying Jami for video-calls between a couple of laptops with Arch and Debian Testing. I've seen that in Arch one can choose JACK as audio server, which is *awesome*. But when tried to connect its ports (in the 'Connections' window of qjackctl) I'd found myself unable to. Is this how it's supposed to be working right now? No, it's not. Pulseaudio is supposed to be for desktop usage and JACK is for low-latency audio, mainly used in multimedia production and studios. I mean: is JACK implemented/usable, at what extent? Sure, it's completely usable, but the application has to support it! [1] Or what should I do to use Jami over JACK instead of PulseAudio?, without PA-bridge, just simple plain JACK.
Jami doesn't seem to support JACK, so you won't be able to use it with "plain" JACK As a workaround, you may have a look at pipewire, which is able to combine Pulseaudio and JACK with low latencies [2]
Thanks a lot in advance for any info. Best regards!
You're always welcome Best regards Oliver [1] https://jackaudio.org/applications/ [2] https://wiki.archlinux.org/index.php/PipeWire
i recommended that the OP post to this list, from a discussion on the jami mailing list - if it is a bug in JACK, this would be the appropriate list - maybe not so, if it is a bug in the jami software - but its not clear if this is a bug in the upstream jami software, or peculiar to one of the arch packages; and this list would be most likely to reach people with some JACK expertise, to determine where the bug lies
oh i should add that, the OP found that the debian package does not create any JACK client, although it is an option in the GUI; but the arch package does create a JACK client - my suspicion was that either: * upstream JACK support is incomplete, and the debian packager noticed that, and disabled it (partially)- if so, then the arch package should probably disable it also or: * upstream JACK support is complete, and but there is something wrong with the arch package or: * upstream JACK support is complete, and there is nothing wrong with the arch package; but the user is using JACK wrong
On Thu, Feb 11, 2021 at 03:55:10PM -0500, bill-auger via arch-proaudio wrote:
* upstream JACK support is incomplete, and the debian packager noticed that, and disabled it (partially)- if so, then the arch package should probably disable it also or: * upstream JACK support is complete, and but there is something wrong with the arch package or: * upstream JACK support is complete, and there is nothing wrong with the arch package; but the user is using JACK wrong
or: * Jami 'supports' Jack via Portaudio, which uses Jack as if it were a sound card. In other words the client will be created only when a call is made. Lots of apps have completely broken Jack 'support' because of Portaudio's broken way of handling Jack. -- FA
participants (4)
-
bill-auger
-
Fons Adriaensen
-
Oliver Friedrich
-
riveravaldez