pa_stream_connect_playback()/pa_stream_connect_record() do not create on default device

Seen with pulseaudio-12.2-9.fc30.x86_64

This is hairy, but I think it boils down to a bug report for the documentation and for module-stream-restore.

The problem as experienced by the user is as follows:

1. Happily use your on board sound card.
2. Start your simple application using playback and recording
3. Stop your application
4. Plug in a USB headset and configure it as the default source and sink
5. Start your simple application again.
6. Microphone on the headset doesn't work

What happens is that module-stream-restore has at some point decided to strongly associate the simple application with the on board sound card, so it overrides the sink and source and gives the simple application something different than the default ones.

The simple application has no UI for choosing sink or source (since it was built to just use the system defaults), so the user is screwed.

Documentation bug

The documentation states:

dev Name of the sink to connect to, or NULL for default

and

dev Name of the source to connect to, or NULL for default

This is not correct for most systems. It should probably state something along the lines of "..., or NULL to let the server automatically chose a sink/source".

This, however, does not give a good user experience. It should be documented that this also requires the application to provide the user with some way of picking sink/source.

Developers could be recommended to specify the magical "@DEFAULT_SINK@"/"@DEFAULT_SOURCE@" instead, but that is easily overlooked. And they aren't mentioned in the documentation right now.

Or we fix:

module-stream-restore bug

module-stream-restore seems way too eager to statically associate sinks and sources with streams. If I go in to GNOME's sound setting and start fiddling with the volume and mute settings then quickly all active streams will have been locked in.

Rather than trying to fix the various corner cases there, I'm going to propose entirely dropping the feature (or at least disabling it by default). The reason being that I do not see a use case for it.

I see two types of applications:

a) Those that do not care about multiple sinks/sources. They should always follow the default sink/source (or what some advanced routing daemon decides).

b) Those that do care about multiple sinks/sources. They will most definitely have their own UI and logic for handling this, so module-stream-restore will just be in the way for them.

I simply do not see what value module-stream-restore provides, and it is definitely causing real world problems.