[LAU] Jack-hardware bridging issue

[Iain Mott]

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.
>