[Freeswitch-users] Stumped by mod_portaudio permissions issue

[Mark Haun]

I built freeswitch version 1.7.0+git~20150730T192909Z~ab7f83c654~32bit for
my ARM-based home server (an NVIDIA Jetson board), with the intention of
using mod_portaudio with a wireless USB headset for my main home phone.  It
works well when running freeswitch directly as root, but when I configured
freeswitch to run at system startup, mod_portaudio could no longer find any
audio devices.

No problem, I thought, it's a simple permissions issue.  I am using the
example debian init script from the wiki (this is a Jessie install with SysV
init rather than systemd).  It runs freeswitch as user freeswitch, group
daemon using the -u and -g command-line options.  So I added "freeswitch" to
the audio group, then used sudo to verify that I could play sound files with
"aplay" as the freeswitch user.  That worked, but it did not solve the
mod_portaudio failure.

Thinking there must be an issue with portaudio separate from ALSA, I fetched
and built the "pa_devs" utility which enumerates and prints the available
audio devices.  (This is basically what mod_portaudio is doing on startup.)
Running as the freeswitch user, that worked too.  Hmmmm.

I tried running freeswitch from the command line using sudo rather than the
-u and -g options, i.e.

$ sudo freeswitch /usr/local/freeswitch/bin/freeswitch -nc

and that worked as well!  Then I started experimenting with -u and -g and
discovered that

$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch

allows mod_portaudio to load correctly, whereas

$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch -g daemon

causes mod_portaudio to fail.

Can anyone explain what's happening here?  In both cases the process UID,
GID, EUID, EGID, FUID, and FGID are the same (freeswitch:daemon) as
displayed with "ps xao pid,uid,gid,euid,egid,fuid,fgid".  Could this be a
bug in freeswitch?  There are a couple of threads from 2-3 years ago in the
archives, where mod_portaudio permissions issues were never resolved and the
solution remained a mystery.

For the time being I guess this (not using -g) is a workaround, but I'd sure
like to understand what is going on.

Mark