Hi @elboulangero

Thanks for that!

The subject has been discussed on Gitter, but before my time. You can pick it out around here:-

https://gitter.im/neutrinolabs/xrdp?at=5b636bd1945df30dc145a3dd

There are also conversations which precede this I suspect. I'm afraid I can't add more than that.

See also this discussion which despite the title touches on what you're talking about. Maybe I'm being naive, but there may be better ways to approach the audio interface which don't pre-suppose a particular audio subsystem. Comments from knowlegeable audio users are very welcome - I wouldn't class myself as one of them.

Hello! Thanks for your answer!

I've read the links that you shared. From my understanding, there was no fundamental blocker then, it's just that the topic of a merge request died off, out of a lack of interest from both parties? Quoting the meaningful part:

Aug 04 2018 04:31
@jsorg71 Iv'e talked with Tanu from pulseaudio, it seems like they want us to prepare a PR of our modules to their new Gitlab
he says he don't remember why they ignored the patch you provided around 4 years ago
http://pulseaudio-discuss.freedesktop.narkive.com/tIT3FKrR/xrdp-pulse-sink#post1
anyway, he sounds positive about getting it into their upstream
we have to move the specific xrdp data out maybe to env vars (our uds socket definitions etc.. )

In any case, the way I see it is:

• upside: if the xrdp module makes it to PA upstream, then for the next PA release, the module will be available in Linux distros. So obviously your users won't have to build the module by themselves, makes life much easier for them.
• downside: if you need to go through a MR every time you want to submit an update, and PA maintainers are not responsive to review and merge it, that will be quite sad...

Of course nothing prevents you from having the latest version of the code in this repo (used for development), and a (possibly older) version in the PA repo.

As for the topic of pipewire, and the best way to support it, I don't really know, I'm not a developer involved in the audio stack myself...

If there's a chance such an application-specific module gets merged into upstream, it would be nice.

One concern is the difference in the release cycle. When we fix some bugs, we can whenever make a new release. If the module get merged into upstream, I'm not sure when bug fixes are delivered to end-users.

Seems like the release cycle of PA is roughly once a year:

$ cd pulseaudio
$ git tag --sort=creatordate --format='%(creatordate:short)%09%(refname:strip=2)' | grep -F '.0'
2006-05-26	v0.9.0
2011-09-27	v1.0
2012-05-11	v2.0
2012-12-17	v3.0
2013-06-04	v4.0
2014-03-03	v5.0
2015-02-12	v6.0
2015-09-24	v7.0
2016-01-22	v8.0
2016-06-22	v9.0
2017-01-18	v10.0
2017-09-05	v11.0
2018-06-18	v12.0
2019-09-13	v13.0
2020-11-23	v14.0
2021-07-27	v15.0

To be back on the topic of packaging: what's a bit blocking to make a proper Debian package is the dependency on Pulseaudio internal library.

Do you happen to know if this dependency is really mandatory, of if there could be a way to do without?

I'm not sure when bug fixes are delivered to end-users

This can always been done via the distro package if it's an important bug fix. I'd be willing to help maintaining the pulseaudio pacakge in Debian, in case it can help.

Actually, I'm not sure about internal dependency. Usually, softwares depend on installed header files as libpulse-dev contains. If it is possible, the module can be built with a standard build process.

Also, thanks for the maintaining packages. I'm also a FreeBSD ports (package) maintainer. Cooperating with package maintainers are very important.

I +1 to go forward.

The internal dependency is on pulse and pulsecore includes, together with the PA config.h. These are not distributed in the pulseaudio development packages, as these are aimed at client applications rather than building PA modules.

I haven't researched some of the below yet, for which I apologise. Due to family commitments this week I'm having to grab odd moments here-and-there on a basic laptop to comment. Feel free to come back at me about anything I've written here which is an obvious non-starter.

Personally I'm in two minds about upstreaming this.

As far as upstreaming goes, there's a bit of effort involved on our part:-

• The interface between PA and xrdp needs documenting in a suitable form. It's possible other projects could make use of this if it's a clean interface.
• There's also the possibility that we could merge the xrdp interface into the existing modules (like the pipe source and sink modules). I haven't looked as this yet. That's possibly more work but could reduce the maintenance overhead in the future.
• I haven't looked at the test drivers we would need to provide to the PA project yet, but I'd imagine they'd want something along those lines.

My biggest concern is once we go down this route, we're stuck with maintaining this interface for ever. If there's a better way to do this, maybe at the protocol level, so we can support systems other than PA we risk having to maintain two systems for the foreseeable future.

Another way to approach this is to suggest to the Debian packagers that they build a pulseaudio-module-dev package when they build the pulseaudio source package. This would have the internal dependencies suitable for building PA modules. This approach would benefits any other group that wants to interface to PA at the module level. It keeps the PA module completely within our control (there are good and bad points to this) and makes it easy to produce a standard Debian package. It doesn't however benefit other distros.

For a link to my conversations with the PA guys.
https://www.spinics.net/lists/pulse-audio/msg20447.html
I think the best solution would be for pulseaudio to support a module api. Similar to what Xorg does. That is probably not likely.
@matt335672 makes a good point, if they accept it, we have to live with it.