Tom, other interested people, I finally got it working on a raspberry pi-4 with buster lite, mostly thanks to the following articles: https://sigmdel.ca/michel/ha/rpi/bluetooth_01_en.html https://sigmdel.ca/michel/ha/rpi/bluetooth_02_en.html https://sigmdel.ca/michel/ha/rpi/bluetooth_n_buster_01_en.html The exact reproducible  steps have been: 1. Started on the basis of + my FreeSwitch installation based on instructions under https://freeswitch.org/confluence/display/FREESWITCH/Raspberry+Pi <https://freeswitch.org/confluence/display/FREESWITCH/Raspberry+Pi> 2. *_sudo apt-get update  && sudo apt-get install -y bluealsa_ * 3. _*sudo vi /lib/systemd/system/bluealsa.service*_ --> substituted ExecStart=/usr/bin/bluealsa with -->Environment=LIBASOUND_THREAD_SAFE=0    ExecStart=/usr/bin/bluealsa -p hfp-hf -p hsp-hs -p hfp-ag -p hsp-ag -p a2dp-source -p a2dp-sink 4. _*sudo vi /lib/systemd/system/bluetooth.service*_ --> Added--noplugin=sapto the end of the following line ExecStart=/usr/lib/bluetooth/bluetoothd 5. _*sudo vi /lib/systemd/system/bthelper@.service*_ --> AddedExecStartPre=/bin/sleep 2in a new line after Type=simple 6. Created a new file by _*sudo vi /etc/asound.conf*_ and added the following as its sole content (if you know the MAC address of your Bluetooth device, substitute it already now; otherwise you can change it also later in step 9): pcm.btAudioIO {         type asym         playback.pcm {                 type plug                 slave.pcm {                         type bluealsa                         service "org.bluealsa"                         device "00:11:09:94:14:3D"                         profile "a2dp"                         delay 10000                 }         }         capture.pcm {                 type plug                 slave.pcm {                         type bluealsa                         service "org.bluealsa"                         device "00:11:09:94:14:3D"                         profile "sco"                         delay 10000                 }         }         hint {                 show on                 description "Bluetooth Audio Input/Output Dvice"         } } 7. *sudo adduser freeswitch audio sudo adduser ***freeswitch *bluetooth sudo reboot * 8. After reboot, run _*sudo bluetoothctl*_and then find, pair, connect and trust your Bluetooth device with the following control commands of this program: *agent on scan on* ****<-- find the MAC address of your device in the scan outputs** *pair 50:11:2D:06:ED:2F ****scan off **connect 50:11:2D:06:ED:2F trust 50:11:2D:06:ED:2F exit *--> from now on, your device should automatically reconnect to the pi each time after the pi is rebooted; if, however, this is not the case, you will have to redo this step after each reboot. 9. In this example, the device that I have paired and trusted has a different MAC address as the one in /etc/asound.conf; therefore we must edit the file and set the right MAC address. If you already had the right MAC address, you may go to the next step without reboot; but, if you had to change the file /etc/asound.conf, then you will have to reboot before going to the next step. 10. Test your device with the following two commands (five seconds recording): *arecord -D btAudioIO -d 5 test.wav aplay ***-D btAudioIO test.wav ** 11. Assuming that the above test is successful, you now - edit <FreeSwitch-Config-Home>/autoload_configs/modules.conf.xml and un-comment the loading of mod_portaudio - edit <FreeSwitch-Config-Home>/autoload_configs/portaudio.conf.xml and substitute the whole content with the following new content: <configuration name="portaudio.conf" description="Soundcard Endpoint">   <settings>     <param name="indev" value="btAudioIO"/>     <param name="outdev" value="btAudioIO"/>     <param name="ringdev" value="btAudioIO"/>     <param name="hold-file" value="$${hold_music}"/>     <param name="dialplan" value="XML"/>     <param name="cid-name" value="$${outbound_caller_name}"/>     <param name="cid-num" value="$${outbound_caller_id}"/>     <param name="sample-rate" value="48000"/>     <param name="codec-ms" value="20"/>   </settings> </configuration>c 12. In my case, I didn't need to do anything for dial plans because in my system both the in- and outbound calls are first handled by my python scripts; in particular, the BT handsfree device is never supposed to make calls but is called for making announcements or invited to a running call as the third leg. So far, I was using an IP telephone with auto-answering capability as extension 000 of my FreeSwitch for this purpose. To substitute that phone with the BT handsfree device, I just needed to update my related python script with the following command: *sudo sed -i 's#user/000@[0-9.]+#portaudio/auto_answer#g' dial.py* After a reboot, after which also FreeSwitch and my application start, everything was working for me just fine :-) Cheers, -- Saied ForwardedMessage.eml Subject: Re: [Freeswitch-users] mod_portaudio on Raspberry Pi currently broken? From: Tom Lynn <tom@tomlynn.com> Date: 27-Jul-20, 07:56 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> I'm in the same boat with portaudio when it's started with systemd.  When I disable it as a service and start it from the command line, pa devlist does return a list of devices.  Still workingon getting a call from portaudio to a station and vice versa.  Calling a station from portaudio device goes to voicemail and in reverse direction I never get a ring indication, just music on hold. On Tue, Jun 30, 2020 at 8:21 PM saiedt <saied.tazari@gmail.com <mailto:saied.tazari@gmail.com>> wrote: Lesley Pervis wrote

Sorry for the spam, but I thought I'd mention that I can aplay no problem from the command line as the 'freeswitch' user, and yet when FS is running as that user, no luck.

Exactly seven years after your last post here, I'm there to ask if you finally succeeded to resolve the issue? My case: 1. Pi-4 with Raspbian buster und latest related FreeSwitch distribution, apt-upgraded and updated just yesterday 2. aplay is working both with the audio jack and with bluetooth (although not simultaneously: as soon as I have a bluetooth audio connection, the audio jack stops to work, and I cannot switch back to it with "amixer cset numid=3 1", but aplay can continue to use the bluetooth connection again after I issue "amixer cset numid=3 65536") 3. it seems that I do not have any permission issue as both pi and freeswitch are in the audio group and related devices under /dev/snd are in that group 4. I have already installed alsaoss, libasound2 and libasound2-dev 5. The output of "pa rescan" in fs_cli is the following: 2020-06-19 06:55:18.803478 [INFO] mod_portaudio.c:3186 Looking for new devices. 2020-06-19 06:55:18.803478 [INFO] mod_portaudio.c:2102 PortAudio version number = 1246720 PortAudio version text = 'PortAudio V19.6.0-devel, revision 396fe4b6699ae929d3a685b3ef8a7e97396139a4' 2020-06-19 06:55:18.943433 [DEBUG] mod_portaudio.c:1773 global indev [-1] 2020-06-19 06:55:18.943433 [ERR] mod_portaudio.c:1777 Cannot find an input device 2020-06-19 06:55:18.943433 [DEBUG] mod_portaudio.c:1786 global outdev [-1] 2020-06-19 06:55:18.943433 [ERR] mod_portaudio.c:1790 Cannot find an output device 2020-06-19 06:55:18.943433 [INFO] mod_portaudio.c:2125 Number of devices = 0 Any clue, what could be wrong on my side? Thanks!

Hi, I have to correct myself with regard to my two posts on Aug 21: 1. I was testing with my headset and had successful "pa looptest" indicating both indev & outdev were working 2. Then, when I tested that in the context of my application for auto-answering incoming calls (I called with my mobile phone while putting it in front of a tv so that I can test if I would hear anything on my headset), I didn't notice that in that case the mic was not working because I had the headset on my ears and was hearing the tv (because of successful looptest, I was just assuming that the mic would also be working) 3. But when I finally got a Plantronics Calisto 620-M Bluetooth Speakerphone, even the looptest failed. At this moment, I tested more carefully my headset again, and there I found out that the mic was not working. 4. Because it seemed that something device-specific should be the reason for failure, I also tested with my bluetooth earphones; there the effect was equivalent to Calisto speakerphone. 5. I finally got a USB speakerphone and tried that one, but in that case I was again back to earlier situation where "pa rescan" failed to find any devices... With all four devices, always arecord and aplay were working perfectly, and the above issues appeared only with mod_portaudio. I don't have any idea what the issue could be with the usb, but with the three bluetooth devices, I still believe that something device-specific should be causing the problems here, e.g. the sample rate. But, currently I am lacking time to further work on this... KR, -- Saied Tazari, Mohammad Reza wrote on 21-Aug-20 18:44:

Tazari, Saied wrote on 21-Aug-20 03:37:

...

6. Created a new file by _*sudo vi /etc/asound.conf*_ and added the following as its sole content (if you know the MAC address of your Bluetooth device, substitute it already now; otherwise you can change it also later in step 9):

This was a very important reason why "pa rescan " had failed for me previously: I had defined the devices in the .asoundrc of the user pi, but freeswitch was running with the user "freeswitch" who has no login shell and hence cannot have any .asoundrc --> device configuration had to go to a user-independent level.

The suggested content for this file tried to get a better output quality by making use of the "a2dp" profile whereas for the mic you have to use the "sco" profile. However, in this combination pa is eventually working in a pretty unstable way. Therefore, we can simplify the content the following way:

pcm.btAudioIO {         type plug         slave.pcm {                 type bluealsa                 service "org.bluealsa"                 device "00:11:09:94:14:3D"                 profile "sco"                 delay 10000         }         hint {                 show on                 description "Bluetooth Audio Input/Output Dvice"         } }

ctl.btAudioIO {         type bluealsa         service "org.bluealsa"         battery yes }

...

10. Test your device with the following two commands (five seconds recording): *arecord -D btAudioIO -d 5 test.wav aplay ***-D btAudioIO test.wav **

You may also perform a loop test:

*arecord -D btAudioIO | aplay -D btAudioIO*

...

After a reboot, after which also FreeSwitch and my application start, everything was working for me just fine :-)

I forgot to say that you can test the working of the setup in fs_cli the following way:

1. "*pa devlist*" should generate an output like "*0;btAudioIO(ALSA);128;128;r,i,o*" 2. Like the test at the level of shell, the actual test can be the loop test: "*pa looptest*"

KR,

-- Saied