On Wed, 2010-01-20 at 11:45 +0000, Colin Guthrie wrote: > 'Twas brillig, and Grzegorz Kryza at 20/01/10 11:13 did gyre and gimble: > > On Tue, 2010-01-19 at 17:33 +0000, Colin Guthrie wrote: > >> 'Twas brillig, and Grzegorz Kryza at 19/01/10 14:06 did gyre and gimble: > >>> Probably as a next step we will follow your suggestions and implement a > >>> specialized PA module to have a better control over a timing. > >>> For sure a better solution but a problematic if a application should > >>> work out of box on a wide set of Linux distributions. > >> > >> It would be nice if you basically taught module-tunnel-* all about > >> compression instead. This has been mentioned in the past but not sure > >> what the current state of affairs is. > > > > Yes, this can be a solution. > > > > Do You know if tunnel sink/source forwards already mixed sound or mixing > > should be done by target PA server? > > > Well a bit of both, but the tunnel itself will carry pre-mixed sound. > > e.g. setup is this: > > > [Local App 1] > +----------+ > | Local PA | > Tunnel > +-----------+ > [Local App 2] > +----------+ | Remote PA | > [Remote App 1] > +-----------+ > > > So Local App 1 & 2 will be mixed and passed out through the tunnel, then > the result will be mixed with Remote App 1 and ultimately output as > appropriate. Good, it's a helpful info. So in theory we can add to our application a PA protocol commands used by tunnel sink/source and use tunnel instead of pipe for communication... Do you think that it will improve a timing control compared to raw communication over a pipes? Thanks. > Col Grzegorz
