[LAU] Jack-hardware bridging issue
Iain Mott
mott at escuta.org
Wed Apr 1 16:24:55 CEST 2020
Hi, thanks, it's the "linphone-daemon" of Linphone 4.1.1 which registers
with an Asterisk server on the same machine. The Linphone desktop app
itself does access the PulseAudio sink in Jack with no problems. However
I'm needing to use the linphone-daemon to which I'm sending commands
with shell scripts via a Unix socket.
I'm running the daemon with a configuration file, eg.
linphone-daemon --config .linphonerc --pipe linphone.soc
It's reading the config, although it seems to ignore the part which
should specify the cards used for playback, capture and ring tone. I
should add that I've found no documentation for linphone-daemon other
than its help file and I'm using the config format for the preferences
file of earlier versions of Linphone. Version 4.1.1 seems to save its
preferences in binary, at least I've not found a text, with a good deal
of searhcing.
I wrote a day ago to the linphone developers list about this. Until now
I've received no reply. I suspect that audio device selection is not
implemented in the daemon and in which case, I'd like to try some sort
of bridging to get the audio into Jack (i need to run both the phone
daemon and SuperCollider though the same sound card and SC only runs
with Jack)
Here's the relevant part of the config:
[sound]
playback_dev_id=2
ringer_dev_id=2
capture_dev_id=3
echocancellation=1
mic_gain_db=0.000000
remote_ring=/usr/share/sounds/linphone/ringback.wav
playback_gain_db=0.000000
local_ring=/usr/share/sounds/linphone/rings/orig.wav
I built the linphone apps from this source:
https://gitlab.linphone.org/BC/public/liblinphone
Em 01/04/2020 10:50, Chris Caudle escreveu:
> On Wed, April 1, 2020 8:06 am, Iain Mott wrote:
>> But it seems that the daemon is bypassing Alsa
>> altogether and connecting to the built in card directly
> That audio hardware is controlled by kernel drivers, user space
> applications would not have access to the hardware directly (possibly if
> there were no other drivers for that interface loaded and you were running
> the software as root, which seems very, very unlikely). If you are
> running the telephony application as root that seems like a very bad idea
> from a security standpoint.
>
> Which telephony application? You were very vague, perhaps if you gave
> more specific details someone on the list is familiar with the software
> and can give relevant advice.
>
More information about the Linux-audio-user
mailing list