On Mon, 2013-07-22 at 22:22 +0200, Thomas Martitz wrote: > Am 22.07.2013 20:11, schrieb Jay Sorg: > > Hi Tanu, > > > >> 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. > > great. > > > >> 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. > > Actually, I did this first. This was an ugly solution. First I did > > the simple API, then the other one. > > The problem is that when you record, you always get data. There is > > not way to know if there is really something playing. I think I was > > looking for zeros to know. But I had to constantly pull the audio > > data so my thread would always be running. > > The sink solution was much better. > > > > Yes, the RDP protocol uses acks and time stamps so you know the clock > > on the client. > > > > > Can it be done in a way that's not specific to xrdp? I.e. that other RDP > clients could also use that module? I assume from the proposed name that > it's xrdp specific If I've understood correctly, RDP clients don't have to implement anything. This is for the RDP server. I'm not sure if there is competition in the RDP server space, but if there is, nothing prevents others from implementing the same protocol. A tempting way to implement this would be as part of PulseAudio's native protocol, so that clients could create sinks. I'm not sure if it makes sense to do that big change for such a niche use case, though (big change conceptually at least; the implementation might not be terribly difficult). -- Tanu
