$PULSE_SERVER: permanent loss of audio in client when facing a transient network problem (networking / virtualization)

[peter]

components: libraries used in the client, I'd assume

version: as distributed with ubuntu 7.10 (64bit)

scenario:

use mplayer -ao pulse in a vmware virtual machine, with $PULSE_SERVER set e.g. to its physical host. Now (vmware-)suspend the virtual machine, then after a short period, resume it. Audio connection is lost (until mplayer itself is closed).

assumptions:

vmware's maybe closing all open connections, and wants all apps/servers/... to reopen them. Which works nicely for all network servers, and should also work for networked audio.

Now the pulseaudio library should try to "recover" the connection, or open a new one, where after some hicups sound should be play properly again (maybe incl. stopping and resuming the playback in the running mplayer). At least for the easy cases, when no stuff/presets/... have been loaded, but we're just outputting to the dsp.

Note that the resuming a suspended VM can be cruelly inefficient for a minute or two, if done via page-ins "in the background" while the vm's already given some cpu-time.

I assume this to be a more generic problem, also occuring with tunnels, etc, pp, whenever some virtualization setup comes into play. It probably will also occur when doing things like changing routing, ip address change, ...

[lennart]

Uh, this is much more difficult than it might seem. Also, if the connection is indeed terminated we get a major discontinuity in the time, which is a big big problem, which is not fixable.

I am thus not sure if we should fix this at all.

[gauss-gs]

I think small sound gap is VERY MUCH better than -KILL-ing and restarting freezed apps (damn skype won the 1st prize for this, second is padsp/alsa-pulse :-!) while pulseaudio crash or network disconnect happens. Maybe just make sound go /dev/null until connection is established by default and let app override this behavior if needed? This is definitely need to fix.

[coling]

@gauss: Just don't talk directly to the remote side. Always create a local PA daemon even if there is no physical h/w. Pulseaudio automatically loads a "Null sink" when no real hardware is present (I could easily make it do the same with sources if there were a null source module!).

By always talking to the local PA daemon there is a much reduced likelihood of any problems. You can then load a tunnel sink to the remote machine and output to the right place as you desire. If there are any network issues, the sink will unload (TCP connection broken) and the auto-null sink will kick in (i.e. exactly what you suggest).

[gauss-gs]

The problem is in connection model, that makes PA clients to freeze indefinitely. It's not a secret that in current state pulseaudio sometimes (wrong! very often!) crashes and makes annoyance to users need to restart freezed applications. Trying to restore lost connection definitely needed for consumer-type audio system. Users doesn't need to think how to restore dead connections, eh...)

[coling]

So you are suggesting that we essentially just accept that PA crashes "very often" and create some kind of wrapper system to deal with this? This seems fundamentally wrong: why not just fix the crashes?

And I really don't think that PA itself crashes "very often" anyway. I've not seen any crash related tickets for a long time. If you have any back traces available, I'll be happy to take a look, but without some kind of information about the crashes you refer to, there is little we can do to help fix them.

Now some kind of auto-reconnect logic is not necessarily a bad idea (I would find it useful when debugging) but this is really something up to the individual clients to implement. I've implemented such features in the various clients I've written, so really other clients need to do the same.

[gauss-gs]

We just mean that pulseaudio CAN crash (of course crashes need to fix) but it need to give smoother user experience by default(if pulseaudio stated as a consumer, not а "professional" sound server), with allow (but not force) client developers to deal with reconnections.

[Rudd-O]

I agree. It makes sense to keep subsystems independent, so if an app casting audio to PulseAudio sees the pulse server die or be inaccessible, this should not cause the app itself to malfunction horribly -- the app should recover gracefully and continue doing what it was doing when the pulse server is restarted.

It's beyond ridiculous to depend on a local pulse server (facilitating an often-secondary function of audio playback) just so apps don't segfault or malfunction. It's good engineering and good design to make apps robust against failure by making the libraries they depend on, do the right thing when something goes wrong.