GNOME Bugzilla – Bug 572630
Tagging Audio Streams
Last modified: 2020-06-06 16:28:46 UTC
http://0pointer.de/blog/projects/tagging-audio.html This is a one-liner, it's portable, it's easy... I think it would be stupid to make it a compile-time option (#ifdef) or push it in the engine. Let's dive!
Quoting from an Email I sent to the Ekiga folks: >> If you tag your streams using the environment variables as described >> in the blog story you'd probably need to adopt libcanberra as >> well. Environment variables are simple to use but are >> process-global. The effect would hence be that the dial/ring sounds >> would be marked as phone call as well potentially causing music to be >> stopped each time ekiga rings. libcanberra has a native PA backend and >> tags streams natively and hence the environment variables don't take >> effect for sounds created with it.
Given that ekiga only supports a single call at a time[1] even an ugly hack like setting the environment variable before the incoming call ring action is taken and then resetting it when the call is picked up -- might work. It would at least be a stopgap to have audio and PA functional until the proper solution is coded up. [1] as far as i have been able to determine -- i.e. when on a call, I don't seem to be able to put that call on hold and take a second (or third, etc.) call and then return to the call on hold when the second call is done -- or bridge the two callers together, etc.
Damien: "use libcanberra for sound events when avaialble".
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.