On Fri, 01.09.06 18:03, Alon Levy ([EMAIL PROTECTED]) wrote: Hi!
> This is my first post to the list, so I'd like to thank you for a great > piece of software, I'm having lots of fun transfering audio between audio > cards, and also between computers. In regard to the later I'm using > module-tunnel-sink - but it seems not satisfactory to me, considering that > it means the audio passes two hops, one to the first server and then another > to the next. Another option that the documentation refers to is using rtp, > but that is basically similar even if with different latency > probably. It the first hop is the local machine i wouldn't call this so "unsatisfactory". > Does anyone think that a way for the server to tell the client to switch to > another server would be a good idea? that would mean only one hop and still > allow changing the target on the fly, which is what one would want if, like > me, he has two computers in different rooms that he wants to listen to the > same music on, but *only when he is in the room*. It's certainly possible to implement a scheme like that. However it wouldn't fit into the current libpulse API in any way. In addition I would argue that this scheme would complicate things by far, while only having minor advantages. Due to buffering in the socket layer the perfomance hit of the current solution compared to your scheme is only minimal. I suggest running a local pa server in setups like yours: always stream the audio data through the local server, and then pass it on to other servers with module-tunnel. This has the nice side effect of mixing multiple local clients before sending them over the LAN, thus minimizing traffic. > Alon Levy > p.s. I'm having problems with the module-tunnel-sink as is but can't provide > any useful information except for saying there is a problem :) more > specifically, has anyone had success in transfering a client from a local > (alsa) sink to a tunnel sink and back again? I fail at the "and back again" > :( The application creating the sound is mplayer, and it just gets stuck at > that point (I'm using padsp mplayer, not the mplayer pulse patch - so maybe > the problem is in padsp?) Hmm? Please elaborate! Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss