On Tue, 2013-07-16 at 10:52 -0700, Jay Sorg wrote: > Hi Tanu, > > Thanks for response. > >> Two questions I have. > >> > >> 1 - is there an easier way to build custom sinks without replacing the > >> PulseAudio system. > > > > I don't think so. We don't support out-of-tree modules. > > OK. > > >> 2 - can I get an xrdp sink into the PulseAudio source upstream? > > > > Yes, if we think that an xrdp sink makes enough sense to justify the > > maintenance cost. Why do you want to have an xrdp sink instead of using > > a tunnel sink that we already support in PulseAudio? > > I looked at the tunnel sink module. It requires another pulse audio > server on the other side and it uses TCP. In RDP, the audio is built > into the protocol. > I looked at all the modules in pulse audio. I didn't see one that fits. > The FIFO module comes close. > What I need is a unix domain socket module with a very simple API for > communication. > I also need to run many on a server at one time so the unix domain > socket name is in an environment variable. > > Is there something like this now? If not, can I submit one? It does > not need to be branded "xrdp" After giving some thought to this (and a bit of research), an xrdp sink seems like a good idea. As you say, it would be more convenient for users than a tunnel module setup. An alternative solution would be to load a null sink, from which xrdp would then record the application output and send to the client, but doing that would mean adaptive resampling somewhere in the RDP software stack to handle the rate deviation between the null sink and the client's sound card. Assuming that the RDP protocol works so that the audio clock is provided by the client sound card, that resampling could be avoided by implementing an xrdp sink. Arun and David, please shout if you hate the idea of an xrdp sink so that Jay doesn't do useless work. -- Tanu
