Add support for PulseAudio

[jojoax]

Pulse Audio ist the given and most common used Audio @Linux Desktops. Without twinkle is unusable in modern Desktopenvironments i.e.: xfce, kde/plasma, Gnome

[fbriere]

While Twinkle does not support PulseAudio by itself, it is quite possible to run it on a system where PulseAudio is used. From what I understand (not being a PA user myself), there are two options:

1) Temporarily disable PulseAudio while Twinkle is running

This is obviously not a great solution, but it might be sufficient if Twinkle is only being used occasionally. One only needs to type pasuspender -- twinkle to suspend PulseAudio and launch Twinkle; the former will automatically be resumed after the latter exits.

2) Configure ALSA to use PulseAudio

This can be achieved by first installing the pulse ALSA plugin (found in the libasound2-plugins package on Debian and its derivatives, alsa-plugins-pulseaudio on Fedora, or pulseaudio-alsa on Arch Linux). Typically, installing such a package will automatically configure ALSA to use PulseAudio by default. See the ArchWiki for more information, or this asound.conf example if you want/need to do it manually.

Be aware, however, that there are reports of bad audio quality with this method, such as https://github.com/LubosD/twinkle/issues/103#issuecomment-365727239 and https://github.com/LubosD/twinkle/issues/9#issuecomment-502433094. (I don't know if this is a universal problem or if it only affects some people; can anyone comment on this?) ~See also #118 for a bug which seems to only affect PulseAudio users.~

[jojoax]

This is not an Option. Since Pulse Audio is Standard in Desktop environments and common used, the ignorance of pulseaudio is a bad, really bad quality and usability issue. Bye. Twinke is dumped here until fixed.

[fbriere]

I would like to emphasize that the absence of support for PulseAudio is not due to willful ignorance, but rather to a simple lack of manpower. According to @LubosD in https://github.com/LubosD/twinkle/issues/9#issue-85640854, getting PulseAudio to actually work properly will require redesigning how Twinkle itself handles audio, which should be no small task. At the moment, no one with enough knowledge and free time to handle this beast has stepped forward.

@jojoax I wish you luck in finding a VoIP client that can better suit your needs; Linphone (which does support PulseAudio) appears to be a popular choice.

[ovari]

@jojoax another software option which supports PulseAudio and SIP is Jami.

All features by client shows the features of the Jami client for each platform. The feature set for the GNU/Linux platform is currently missing Group chat and Chat history shared across devices; however, the developers have stated on their Blog that these features are currently being implementing.

In addition to SIP, Jami also supports distributed hash table (DHT) technology. Multiple DHT and SIP accounts are supported concurrently.

If your Linux distro is not shown on the Linux Download page, it might be available at the Contributions page.

If you have any issues with Jami, their issue tracker is monitored and bugs fixed promptly on their Git instance.

Hope this helps.

[mauromol]

PulseAudio support could allow to use Bluetooth headsets easily with Twinkle.

[jose1711]

i am ready to add 30 € if someone implements it (thought i don't need it but then my parents come and they want to be able to switch between headphones and speakers in realtime..)

[Knogle]

Any news about that issue? I'm also having issues with the lacking PulseAudio support. Also ready to pay for the work.

[oscarfv]

i am ready to add 30 € if someone implements it (thought i don't need it but then my parents come and they want to be able to switch between headphones and speakers in realtime..)

For the record: in my Debian box with KDE I can seamlessly switch between headphones and speakers, although I had to configure Pulseaudio for not playing sound simultaneously on both devices. In fact, I'm using an script for playing the incoming call ring tone on the speakers and automatically switch to headphones when I answer the call.

At first I missed some key features on Twinkle and even discarded it at first, but once I learned about the scripting feature, I quickly adapted it to my needs and now I'm very happy with it. I don't see the urgent need of directly supporting Pulseaudio on Twinkle. After all, Pulseaudio is a layer on top of ALSA.

[jose1711]

For the record: in my Debian box with KDE I can seamlessly switch between headphones and speakers, although I had to configure Pulseaudio for not playing sound simultaneously on both devices. In fact, I'm using an script for playing the incoming call ring tone on the speakers and automatically switch to headphones when I answer the call.

At first I missed some key features on Twinkle and even discarded it at first, but once I learned about the scripting feature, I quickly adapted it to my needs and now I'm very happy with it. I don't see the urgent need of directly supporting Pulseaudio on Twinkle. After all, Pulseaudio is a layer on top of ALSA.

Can you please tell how does your solution cope with situation when headphones are physically disconnected/reconnected during call? Is it possible to configure headphones as ring-out device but only if the device is present?

[oscarfv]

Can you please tell how does your solution cope with situation when headphones are physically disconnected/reconnected during call? Is it possible to configure headphones as ring-out device but only if the device is present?

I never disconnect the headphones, but I think that Pulseaudio will switch to the speakers automatically when you disconnect your headphones. You can try it yourself. For switching back to the headphones when you connect them, I also think that Pulseaudio does that by default.

As for your second question, pacmd list-sinks shows:

...
       ports:
                analog-output-lineout: Line Out (priority 9000, latency offset 0 usec, available: yes)
                        properties:

                analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: yes)
                        properties:
                                device.icon_name = "audio-headphones"
        active port: <analog-output-lineout>

Note the available: yes piece, that seems to be the info you need.

[jose1711]

I must confess I am a bit lost. Twinkle allows me to enter ALSA or OSS device in System Settings - Audio - Ring tone. What would I need to put it in other to ring headphones (separate device in case of Jabra headphones) if available, otherwise use internal soundcard? Also you mention that "Pulseaudio will switch to the speakers automatically" - but what this has to do with Twinkle which accesses devices via ALSA, not PA?

[oscarfv]

I must confess I am a bit lost. Twinkle allows me to enter ALSA or OSS device in System Settings - Audio - Ring tone. What would I need to put it in other to ring headphones (separate device in case of Jabra headphones) if available, otherwise use internal soundcard? Also you mention that "Pulseaudio will switch to the speakers automatically" - but what this has to do with Twinkle which accesses devices via ALSA, not PA?

Audio device management is accomplished entirely on the script invoked by Twinkle. Audio preferences in Twinkle remain with default values.

This is a simplified part of my script (the programming language is Tcl):

proc activate_speakers {} {
    exec pacmd set-sink-port @DEFAULT_SINK@ analog-output-lineout
    exec pacmd set-sink-mute @DEFAULT_SINK@ off
    exec pacmd set-sink-volume @DEFAULT_SINK@ 30500
}

proc activate_headphones {} {
    exec pacmd set-source-mute @DEFAULT_SOURCE@ off
    exec pacmd set-source-volume @DEFAULT_SOURCE@ 40000
    exec pacmd set-sink-port @DEFAULT_SINK@ analog-output-headphones
    exec pacmd set-sink-mute @DEFAULT_SINK@ off
    exec pacmd set-sink-volume @DEFAULT_SINK@ 60500
}

set trigger $env(TWINKLE_TRIGGER)

if { $trigger == "in_call" } {
    activate_speakers
} elseif { $trigger == "in_call_answered" } {
    activate_headphones
} elseif { $trigger == "out_call" } {
    activate_headphones
}

It also sets volume and unmutes. Most likely the parameters for the the pacmd invocations need to be different on your setup. Specifically, you probably need to change @DEFAULT_*@ to the correct source and sink names. pacmd list sources/pacmd list sinks have all the info you need. Note that pacmd is a Pulseaudio tool.

As for automatically swithching to headphones/speakers when you connect/disconnect the headphones, have you actually tried it? The switch is performed by Pulseaudio, not Twinkle. If your headphones work as a different audio card, you might need to do some Pulseaudio configuration (ask on some Pulseaudio forum).

[jose1711]

Thank you for sharing, I am really glad it worked for you but I feel it's kind of a stretch having to learn a programming language (and internals of Pulseaudio) to configure this. Still hoping someone implements PA support one day..

[userofryzen]

@LubosD it's stop, right? sorry for not be helpful in code, i can only "test"

[oscarfv]

PulseAudio is being deprecated in favor of Pipewire.

I'm using Twinkle 1.10.2 (as packaged by Debian) with Pipewire with no issues. I had to configure echo cancellation (as previously had with PulseAudio) and adapt my scripts to use pactl instead of pacmd to switch to/from headphones, set volume, etc. Pipewire's pactl is a drop-in replacement for PulseAudio's pactl.

[userofryzen]

@oscarfv i'm using it with wayland plasma and pipewire too. But i'm asking more about the general project. there is no new version since.. years I think, rigth? nevermind I understand Lubos is not in place to maintain this. I would tag a new version so the new version will have g722 for example.

[oscarfv]

@userofryzen : no new version but the project is active, as proven by the commit log.

[userofryzen]

https://github.com/LubosD/twinkle/issues/206 I said for this issue that is opened without risponse so much time ago

El vie, 11 feb 2022 a las 16:38, oscarfv @.***>) escribió:

@userofryzen https://github.com/userofryzen : no new version but the project is active, as proven by the commit log.

— Reply to this email directly, view it on GitHub https://github.com/LubosD/twinkle/issues/161#issuecomment-1036342254, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH5RQUO7I4N3IMAXZPNGTC3U2UUPVANCNFSM4IXAN73A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[fbriere]

I'm using Twinkle 1.10.2 (as packaged by Debian) with Pipewire with no issues.

I was wondering if anybody had tried this and could report back. Thanks @oscarfv!

That said, from your previous comments, it doesn't seem like you were having issues with PulseAudio previously either. Was I naïve in hoping that PipeWire would magically make all our problems go away?

[Cyborgscode]

Twinkle 1.10.3 Fedora 35 x64 works fine with PulseAudio and Pipewire.

Suggest to CLOSE this issue.

[tormodvolden]

Twinkle works great with PipeWire's ALSA client support. Thanks to the discussion here I got curious enough to install PipeWire on Ubuntu 20.04 (PPA and instructions here) and Twinkle Just Works, while playing sound from other applications (ALSA, pulseaudio or jack clients) at the same time. Using e.g. qpwgraph (see screenshot below) you can easily reroute input and output live to/from multiple devices, with mixing out of the box. Bye bye pulseaudio server :)

[luizluca]

For me, it works 50/50 with pipewire. Sometimes it works, sometimes it does not.

+++ 13-6-2022 17:44:32.124498 INFO NORMAL t_alsa_io::open
Opening ALSA device: default
play
capture
---

+++ 13-6-2022 17:44:32.124505 INFO NORMAL t_alsa_io::open
Opening ALSA device: default
play
---

+++ 13-6-2022 17:44:32.124846 CRITICAL NORMAL t_alsa_io::open
snd_pcm_open failed: Device or resource busy
---

+++ 13-6-2022 17:44:32.124875 CRITICAL NORMAL t_audio_io::open
Open audio device failed
---

Other alsa clientes (like aplay) also fails. It works after restarting pipewire:

systemctl --user restart pipewire

Although it is not specific to twinkle, it is a reason to migrate to PA (or others).

[tormodvolden]

For me, it works 50/50 with pipewire. Sometimes it works, sometimes it does not.

Without information about your PipeWire version, kernel, distribution, etc it is difficult to evaluate the relevance of your observation.

Other alsa clientes (like aplay) also fails. It works after restarting pipewire:

This, on its own, seems to indicate a bug in your version of PipeWire.

Although it is not specific to twinkle, it is a reason to migrate to PA (or others).

If there were PulseAudio support in Twinkle today, this issue would be a reason for you to use PulseAudio. However, even if all resources available for Twinkle were focused on adding this support, it would still take a long time before it would be usable. By that same time, PipeWire will probably have improved much, resolving your issues and many others. OTOH, other people's issues with PulseAudio may not ever get fixed. PulseAudio is a dead horse. Subjectively I would add, it has greatly improved from a nightmare to a mostly usable product but it will not get any further.