as of pulseaudio-1.0, module-tunnel-sink is the only usable way of putting the sound through a networked sound server. It does have the theoretically nice feature of live stream migration, but in practice it's just unstable as hell. Youtube plays only the sound while the video is frozen. Xine crashes after switching between networked and local sound twice. Note that when using a direct connection to the networked server without a tunnel sink, everything works fine (apart from the occasional glitch). I think this should be fixed before >=media-sound/pulseaudio-1.0 stabilization since it's a major regression. I haven't checked what upstream knows about this issue yet, but I do know about this other bug which also breaks module-zeroconf-discover (which should automatically add local tunnel sinks for networked sinks) in conjunction with IPv6-enabled avahi: http://pulseaudio.org/ticket/694 This has been sitting there for two years now, which looks to me like upstream is neglecting network functionality a bit. See also http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-December/012474.html . The IPv6 issue seems trivial enough, but right now I don't have enough time to investigate those pretty serious playback issues. Reproducible: Always
You can read the reply to the email you pointed to for upstream's take on the issue -- http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-December/012478.html (tl;dr: misbehaving clients become much more apparent on network sinks, and there's a lot of those that we have no control over. Also, the network sink needs some love, but there isn't anyone volunteering to work on it at the moment.) With that out of the way, are you saying that stream moves to a tunnel sink worked fine at some point? If yes, some more information (like what what version it last worked in) would be helpful.
> With that out of the way, are you saying that stream moves to a tunnel sink > worked fine at some point? If yes, some more information (like what what > version it last worked in) would be helpful. Nope, I never tried tunneling a network sink before, but as I read it, the unreliability is simply due to the current status of tunnel and client code. I think the shortcut to fixing the issue is in this forum post: http://forums.gentoo.org/viewtopic.php?p=6914120#6914120 Colin also stated on pulseaudio-discuss that re-implementing the old, reliable functionality of telling the client to connect to a networked server via the PULSE_SERVER property of the X11 root window should be straightforward. This could be easily implemented in pasystray and we'd have a quick solution while module-tunnel-sink is being fixed (which will take some time I think).
Is this still valid with latest pulseaudio?
(In reply to Pacho Ramos from comment #3) > Is this still valid with latest pulseaudio?
