Add support for the portaudio library

[dubnemo]

I understand you have a Jack wrapper implementation, but native alsa may provide even better performance on the raspberry pi for Jamulus clients leveraging HiFiBerry DAC+ ADC boards.

[corrados]

Can you prove that? I run Jamulus on a Raspberry Pi Zero with Jack. I do not think direct ALSA interface can improve the performance. Maybe some Jack Audio developer can comment on that.

[mirabilos]

JACK also uses ALSA in the backend, because ALSA is what the kernel provides (that, or OSS).

So, as long as you have only one application using sound running, ALSA has much less overhead (less processes ⇒ less RAM and less context switches).

I’d prefer ALSA on Linux but have JACK as an option (e.g. for proper musicians who use it anyway), but we need JACK on GNU/kFreeBSD and GNU/Hurd in Debian because these don’t have ALSA because they don’t use the Linux kernel, so ideally both would be available and the user could choose.

[trebmuh]

JACK can use ALSA in the backend, but it can use a bunch of other backends too (think FFADO as an example).

[corrados]

See this commit: cb951c9 and also this: https://github.com/corrados/jamulus/blob/master/ChangeLog#L368
We have an audio interface for ASIO, CoreAudio, Jack and Android (under development). I actually do not want to have another one...

[dubnemo]

My HiFiBerry DAC+ ADC has shipped (Switzerland -> Minneapolis US), and it is only accessed via ALSA interface. My guess is the coverage of the implementation of ALSA within Jack.
I too have Jamulus working on RPi4 in listening mode only. Need the ADC for full functionality. I will have proof when I receive and test -- I suspect I will be OK.

[mirabilos]

Scott T Nieman dixit:

My HiFiBerry DAC+ ADC has shipped (Switzerland -> Minneapolis US), and it is only accessed via ALSA interface.

JACK uses ALSA by talking to the ALSA interfaces the same way an application directly using ALSA would.

My guess is the coverage of the implementation of ALSA within Jack.

This makes no sense. If it works without JACK it will work with JACK. (If jackd starts. I had a case today on a laptop infested with poetteringaudio where we couldn’t get it to. On another, it worked. Both not mine, I ofc know better…) corrados dixit:

We have an audio interface for ASIO, CoreAudio, Jack and Android (under development). I actually do not want to have another one...

Fair enough.

[dubnemo]

@mirabilos

This makes no sense. If it works without JACK it will work with JACK.

Really.
So are you saying that JACK implements 100% of the ALSA interfaces?
https://www.alsa-project.org/alsa-doc/alsa-lib/files.html

An application may choose to implement what it needs for the scope of its functionality; e.g., MIDI (rawmidi.h) may be out of scope. That is what is typically is called 'coverage', at least in my 30+ years of development.

[mirabilos]

Scott T Nieman dixit:

>> This makes no sense. If it works without JACK it will work with JACK. Really. So are you saying that JACK implements **100%** of the ALSA interfaces?

I’m not. I’m saying that JACK implements 0% of the ALSA interfaces, because it *uses* ALSA (not substitutes it).

[elliotclee]

@corrados Could you just switch Jamulus to using portaudio (portaudio.com) as its audio API? It would relieve you of the need to maintain code for multiple audio APIs, and it would add support for additional audio interfaces (e.g. WDM-KS on Windows). It's also the library that Jack itself uses.

[corrados]

Jack on Linux uses portaudio?

[elliotclee]

Not on Linux. Definitely on Windows, maybe on Mac (git has libportaudio.a but I'm not sure it's still used).

Does the portaudio API provide adequate functionality for Jamulus' needs?

[corrados]

Does portaudio support the Google Oboe library for Android? We are currently working on a new audio interface implementation for Jamulus for Android which uses the Oboe library, see #83

[elliotclee]

Good question. Looks like the official Portaudio is mainly a Win/Mac/Linux deal. There is a port of portaudio to opensles at https://github.com/Gundersanne/portaudio_opensles/tree/master/src/hostapi/opensles but that's the old Android API. I can't find any port of portaudio to AAudio or Oboe.

It might be just as much work to add Oboe support to portaudio as it would be to update the Jamulus audio code to support all the other platforms it would be nice to have. E.g. using portaudio would allow switching between ASIO and Jack at runtime on Windows, and allow also using WDM-KS devices.

[corrados]

Yes, I see the advantages of portaudio. It is definitely much better to include portaudio than ALSA directly (as is the title of this Issue). But right now I do not see an urgent need of including portaudio. Maybe we should change the title of this Issue and work on a portaudio integration sometime later (maybe when the peak of Corona is over and we have more time for other stuff).

[corrados]

Since portaudio supports ALSA directly, I will change the title of this Issue now to better reflect the ongoing discussion here.

[dubnemo]

I will have time to fully test this Wednesday evening Central (us).

After editing jamulus.desktop, I have now have the Jamulus client running and connected to my local server in my studio basement. The previous performance with the Hi-Fi Berry ADC-DAC was ~80ms total roundtrip, and this is about 1/2.

I am not sure about the Pulse device, but again, I will test this out.

pi@raspberrypi:/usr/local/share/applications $ sudo nano jamulus.desktop
pi@raspberrypi:/usr/local/share/applications $ cat jamulus.desktop
[Desktop Entry]
Name=Jamulus
Comment=Jam Session
Comment[fr]=Séance de bœuf
Comment[sv]=Musikaliska jamsessioner över Internet
GenericName=Internet Jam Session Software
GenericName[fr]=Logiciel de séance de bœuf sur Internet
GenericName[es]=Software para Jam Sessions por Internet
GenericName[pt]=Software para Jam Sessions pela Internet
GenericName[nl]=Software voor jamsessies over internet
GenericName[sk]=Softvér na džemovanie cez internet
GenericName[sv]=Mjukvara för Jam Sessioner över Internet
Exec=Jamulus --api ALSA
Icon=jamulus
Terminal=false
Type=Application
Categories=AudioVideo;Audio;Mixer;Qt;
Keywords=jam;live;online;music;conference;

When I select the Hi-Fi Berry from the Device drop-down directly, it is throwing an exception. But that may be a configuration issue.

[jujudusud]

Nice !
@npostavs: do you need X86_64 Linux and windows 10 64 bits testers ?

I want to test Windows WASAPI to use it instead of asio4all.

P.S.: No need to use OSS server in 2022 from my point of view.

[dubnemo]

@npostavs: I woke up in the middle of the night thinking the Hi-Fi Berry device should work, as there isn't much to configure. I only edited the /boot/config.txt

# use the headphone output jack on the RPi4
dtparam=audio=on
# enable DAC+ ADC Pro
dtoverlay=hifiberry-dacplusadcpro

#Disable Wifi; use eth0 for Jamulus only
dtoverlay=disable-wifi 
# disable bluetooth
dtoverlay=disable-bt

I have not created ~/.asoundrc (my user only) or /etc/asound.conf (all users) files.

There may have an interface mismatch with the number of channels(?).

[npostavs]

I want to test Windows WASAPI to use it instead of asio4all.

You can give it a shot, although I found the results disappointing on my hardware (run Jamulus with --api WASAPI to activate). Note that you can also try KoordASIO instead of asio4all; it uses WASAPI via PortAudio too (and likewise doesn't seem to work well with my hardware).

There may have an interface mismatch with the number of channels(?).

Hmm, I'm not sure what's triggerring that error.

[dubnemo]

@npostavs I thought you'd like to know that I am getting the same error with the channel interface.

Just to be clear the configuration

pi@raspberrypi:~ $ cat /proc/asound/cards
 0 [Headphones     ]: bcm2835_headpho - bcm2835 Headphones
                      bcm2835 Headphones
 1 [vc4hdmi0       ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 2 [vc4hdmi1       ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1
 3 [sndrpihifiberry]: HifiberryDacpAd - snd_rpi_hifiberry_dacplusadcpro
                      snd_rpi_hifiberry_dacplusadcpro

pi@raspberrypi:~ $ cat /proc/asound/devices
  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 32: [ 1]   : control
 33:        : timer
 48: [ 1- 0]: digital audio playback
 64: [ 2]   : control
 80: [ 2- 0]: digital audio playback
 96: [ 3]   : control
112: [ 3- 0]: digital audio playback
120: [ 3- 0]: digital audio capture

Works in Audacity:

But I get the error when selecting the device in the Jamulus client:

Really unrelated, but I am unclear why PulseAudio daemon is referenced, even when I remove it:

pi@raspberrypi:~ $ sudo apt-get purge pulseaudio
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libpulsedsp pulseaudio-utils rtkit
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  lxplug-volumepulse* pulseaudio* pulseaudio-module-bluetooth*
0 upgraded, 0 newly installed, 3 to remove and 48 not upgraded.
After this operation, 6,919 kB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 95430 files and directories currently installed.)
Removing lxplug-volumepulse (0.12) ...
Removing pulseaudio-module-bluetooth (14.2-2+rpi1) ...
Removing pulseaudio (14.2-2+rpi1) ...
Processing triggers for man-db (2.9.4-2) ...
(Reading database ... 95179 files and directories currently installed.)
Purging configuration files for pulseaudio (14.2-2+rpi1) ...
Processing triggers for dbus (1.12.20-2) ...

oddly it still shows up when I start the Jamulus client:

pi@raspberrypi:~ $ ps -ef | grep pulse
pi           653     632  1 22:35 ?        00:00:27 /usr/bin/pulseaudio --daemonize=no --log-target=journal
pi          3136    1613  0 23:09 pts/0    00:00:00 grep --color=auto pulse

And the PulseAudio sound server interface seems to be working (I will check my server recording). If this daemon can be bypassed and go direct via PortAudio like Audacity, I suspect the total delay can be further reduced.

[dubnemo]

PortAudio seems to use PulseAudio sound server. I went into Audacity again, then killed pid 632, and the RPi4 screen went blank and restarted with the login screen.

[elliotclee]

Pulseaudio is one of the daemons that get started with the login session, so it's not surprising that the session ended when you killed it. Now that you've removed the pulseaudio package and killed the process, can you login again and get Jamulus to run? Elliot

…

________________________________ From: Scott T Nieman ***@***.***> Sent: Thursday, March 31, 2022 9:02:15 AM To: jamulussoftware/jamulus ***@***.***> Cc: elliotclee ***@***.***>; Mention ***@***.***> Subject: Re: [jamulussoftware/jamulus] Add support for the portaudio library (#116) PortAudio seems to use PulseAudio sound server. I went into Audacity again, then killed pid 632, and the RPi4 screen went blank and restarted with the login screen. — Reply to this email directly, view it on GitHub<#116 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJNWQFHJN5WKIWVVGONZTYLVCWO5PANCNFSM4ML7LMQA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dubnemo]

@elliotclee yes, you are correct. It is not spawned by PortAudio. Jamulus client saw PulseAudio and that was able to communicate to the HiFi Berry card in my earlier screenshots, hence why it was able to start. Now after restart of the RPi4, I now see this on startup of Jamulus client.

@npostavs do you think there a PortAudio callback that is not set properly? Audacity still works after uninstall of PulseAudio too. Is there a way to turn on fine logging in the client via a cli parameter?

[npostavs]

I haven't added a logging option; I'm not really what there is to log.

You could try fiddling with the setting of paInputParams.suggestedLatency in src/portaudiosound.cpp, I did find that I got some confusing errors on Windows when it was set to the wrong value (and it's still unclear to me how to know the right value).

Might also be worth investigating whether any the functions in http://files.portaudio.com/docs/v19-doxydocs/pa__linux__alsa_8h.html helps. At least PaAlsa_EnableRealtimeScheduling seems relevant.

[dubnemo]

@npostavs
Curious what is in devInfo for the Hi Fi Berry, as it has a 35mm stereo input and two RCA outputs available out of the box, but it appears there are balanced inputs and outputs available on the board with soldering.
From above:

112: [ 3- 0]: digital audio playback
120: [ 3- 0]: digital audio capture

One of the above errors showed 'invalid number of channels'.

[dubnemo]

It seems more on the device initialization, versus streams.

http://files.portaudio.com/docs/v19-doxydocs/api_overview.html
Although each Device conceptually belongs to a specific Host API, most PortAudio functions and data structures refer to Devices using a global, Host API-independent index of type PaDeviceIndex an integer of that ranges between zero and Pa_GetDeviceCount() - 1. The reasons for this are partly historical but it also makes it easy for applications to ignore the Host API abstraction and just work with Devices and Streams.

If you want to enumerate Devices belonging to a particular Host API you can count between 0 and PaHostApiInfo::deviceCount - 1. You can convert this Host API-specific index value to a global PaDeviceIndex value by calling Pa_HostApiDeviceIndexToDeviceIndex().

=====
deviceCount -1 may be relevant.

Do you really want to iterate on the api count or the device count?
for ( PaHostApiIndex i = 0; i < apiCount; i++ ); ... selectedApiIndex = apiIndex;

selectedApiIndex is passed as an argument to Pa_HostApiDeviceIndexToDeviceIndex

PaDeviceIndex outDevIndex = Pa_HostApiDeviceIndexToDeviceIndex ( selectedApiIndex, j );

[ann0see]

Hi, Sorry for the maintenance noise here. I’m just into triaging issues.

As I understand, currently, this issue needs some more discussion and is not actionable yet. I’ve therefore moved it to a GitHub discussion to maintain more visibility. Please note that GitHub Discussions – different to GitHub issues show up high if there is discussion.
So feel free to continue discussion on GitHub discussions instead of GitHub issues.

Great to know that PortAudio gets some love again ;-).

[dubnemo]

Interesting. I expected the issue would be linked to this specific branch. This is very close, and I was looking to see how Audacity uses the device interface.

…

On Fri, Apr 22, 2022, 1:14 PM ann0see ***@***.***> wrote: Hi, Sorry for the maintenance noise here. I’m just into triaging issues. As I understand, currently, this issue needs some more discussion and is not actionable yet. I’ve therefore moved it to a GitHub discussion to maintain more visibility. Please note that GitHub Discussions – different to GitHub issues show up high if there is discussion. Great to know that PortAudio gets some love again ;-). — Reply to this email directly, view it on GitHub <#2606 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQOZXV6FWKQH4RJCG2XDVGLT6ZANCNFSM5UDAYU2Q> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[dubnemo]

@ann0see so was this issue and branch ever resolved and merged? Moving this to a discussion certainly killed the conversation, counter to your goals.

[ann0see]

No. Unfortunately I don't think much moved on. It somewhat works unreliability.

Maybe @npostavs worked on something?

[dcorson-ticino-com]

From the work done up 'til now we have seen no improvement in the sound or delay using portaudio, and it has been highly unstable.
If someone wants to step in and work on this development they are very welcome.

[dubnemo]

There is a bug as noted in the original issue, it was NOT setup correctly to use Portaudio *directly *as shown by my testing screen shots. Hence why there is no improvement.

…

On Wed, Mar 1, 2023 at 7:49 AM DonC ***@***.***> wrote: From the work done up 'til now we have seen no improvement in the sound or delay using portaudio, and it has been highly unstable. If someone wants to step in and work on this development they are very welcome. — Reply to this email directly, view it on GitHub <#2606 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXOQOYTOPTODKIYZGRFU7LWZ5HXPANCNFSM5UDAYU2Q> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>