https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #18 from [email protected] 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. _______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
