[pulseaudio-tickets] [Bug 50256] pasuspender alsa hook test fix.

Tue Jun 12 19:14:10 PDT 2012

https://bugs.freedesktop.org/show_bug.cgi?id=50256

--- Comment #18 from oiaohm at gmail.com 2012-06-12 19:14:10 PDT ---
Tanu Kaskinen the more I think about this problem the worse it gets in the near
term future.

Systemd implements cgroups around user-sessions.  This now brings the evil
where a user-session could be suspended to disc and restarted at a later time. 
So hardware change on fly is going to be a possible reality for all
applications not just wine.

https://lwn.net/Articles/495304/  This in Linux 3.5 allows cgroup states to be
shoved between servers for stuff just using network.

http://www.criu.org/CR_tools was able todo the networking side in userspace. 
So it should be possible to resolve the audio in userspace as well.

Also remember systemd implements multi-seat as well so a session might not be
restored on the same seat.

The more I look at this Environmental vars are nothing more than a short term
fix.  Reason why bluez for bluetooth audio cannot bolt perfectly into alsa is a
lack of means to update alsa settings on fly as bluetooth devices are added. 
Alsa complete issues with add and remove hardware on fly link to its
configuration system.

So might as well abuse ALSA_CONFIG_PATH for now.  Because it will make this
problem work for now.

Really the true fix is somehow break alsalib from being dependant on static
audio state and be able to change on fly.  So be able to cope with hardware
being added and removed on fly without restarting applications.  Most likely a
dbus server storing audio config.   

Fixing alsalib also would pull jack1 in and possibly would have avoided the
need for the dbus link between jack2 and pulseaudio.  Since when jack2
attempted to connect to alsa by alsalib pulseaudio could have detected and
moved aside.

Basically move the dbus link between sound servers down to alsalib.

One of the biggest things I hate about pulseaudio is the duel driver
requirement being a duel set of probing in applications.  Was worse when there
were more sound servers.  There has never been a place in the system to go and
look up and go ok the system running this sound server and its working in a
generic way.  So there is really a place for a audio description in dbus.  It
is possible to have dbus give different answers based on application requesting
as well.  So a case of jackaudio and pulseaudio running side by side some
applications could be directed to jackaudio and some could be directed to
pulseaudio and some possibly told to change.

A shared application audio config control on dbus between pulseaudio jackaudio
and alsa would make the audio stack work and most likely fight less with each
other.

Being able to make alsalib respond to a shared configuration alterations also
has some advantages for pulseaudio.  You need to mute a alsalib application so
you tell alsalib to send all sound to dummy pcm.  This way none of the sound
the application is producing gets transfered out of the alsalib application. 
So reducing memory copies.  This should also reduce power usage.  Also you
don't need this duplicated in the pulse pcm driver for alsa.

Done right does not great per application volume control to alsa but does grant
mute to alsa.

Also allows you to remove alsa applications without permission tunnelling under
pulseaudio by mistake.  With real hardware interfaces that wine currently can
tunnel to would not be displayed to the application running under pulseaudio.

There is a sandbox issue here as well.  If an application can see a different
path other than what it should take someone will take an application that path.

The tunneling under by mistake wine can do in my eyes should not even be
possible to do.  Like trying to connect to sysdefault when should be going to
default because audio need to redirect to pulseaudio because pulseaudio is
sitting on the output.  Hardware with mixing allows a double connection  so
bring interesting management problems.

Blocking the tunneling also requires fixing how alsalib does it configuration. 
A configuration server would allow configuration to change on mode.

Just like you say its not suitable to have to log out to change environmental
vars its not really suitable that users have to stop applications to change
sound servers or backends either.  Needs to be transparent to user.  I dropped
back to alsa and everything kept on work or I started pulseaudio and everything
kept on working or I started to jack and I want that audio feed to go to jack
from the applications I have running.

Basically its a flexibility that is missing.  So forcing people to decide
between alsa jackaudio and pulseaudio.  That lack of flexibility makes a lot of
stuff only half done right like bluetooth audio.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.