https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #6 from [email protected] 2012-05-27 18:19:54 PDT --- "I thought the use case was comparing, for debug purposes, application behavior when using pulseaudio and when using direct alsa. In such cases mixing is not usually needed. pasuspender should never be "the solution" to audio problems with open source software such as wine. pasuspender is only a debugging tool, or a workaround for proprietary software that can't be fixed." That is the problem you debugging case is wrong. For wine to debug we need perfered to see as if pulseaudio never touched alsa. Even with dmix and alsa we are very suspect that this avoid a issue. We cannot get enough testing to fully prove it because people want there game to work now with the least editing of stuff. Simple problem is wine is heavy at times. We suspect wine ends up hogging the cpu time and ram in multi small processes with a low OOM Killer preference so basically pushing Pulseaudio into being killed by kernel. So pulseaudio screws up due to resource starvation caused by way some programs run in wine. Basically Pulseaudio killed because its a sound server. Now this would become very clear if Pulseaudio is disabled and the kernel kills it. If this is the case Pulseaudio working with wine without better process control is impossible. This behaviour of wine to pushing audio servers under the pre-verbal bus not new. Result might be Pulseaudio with wine limited to systems with systemd and ulatencyd so wine cannot push sound server into the OOM Killer as the only existing safe way to run the combination. Just to be clear it is the "proprietary software" in wine that causes wine to open so many sub processes at times. This is not something wine can change. So not fixable from the wine side. This is something you doing pulseaudio are not considering wine will at times have evil tendencies to resource usage because windows programs are use to getting away with it. So not all breaks of pulseaudio will track to audio output of wine. Some with just track to wine being wine and resource management in the distribution not being up to it. We do need to be able to prove this as well perfered without having to tell users to uninstall pulseaudio. "In any case, feel free to replace hw:0 in my example with sysdefault, if the lack of mixing is a problem when debugging. Are "sysdefault's" semantics defined somewhere, btw? It's not documented at [1] at least. I doubt that it actually guarantees anything about mixing - my guess would be that "sysdefault" just happens to be usually be defined as card 0 with dmix, and therefore it usually also supports mixing." sysdefault is define as what alsa would have setup as default if pulseaudio and nothing else had touched it. This is in the source. Default under alsa is define as having mixing or the card configuration is defective. So yes its look up alsa define for default then see that sysdefault is just a non tampered with version. So wine is able to work with this. Where sending it straight to hardware does not work. So sorry it is defined. Sysdefault is a hack in alsa added to work around the fact the pasuspender and other sound servers when suspended have the defect of leaving default a non operational state. Wine is based on the fact default works unless the alsa card config is defective. This is where pasuspender becomes a problem. The default you expose is basically disabled and at times broken. Throwing back error that sound card is non functional because pulseaudio is disabled. So basically creating a defective alsa state that is not meant to exist and is confusing to applications. Problem comes in that wine is just like running a http server. It can fork parts off and lose track of them so blocking pulseaudio from being able to leave suspend this most likely will require a cgroup solution or equal done somewhere. You have presumed that testing can be done by skilled people. With item like wine we cannot afford todo this its just budget impossible. Since the skilled people cannot afford to buy all the software to test it. With wine not all out testers are skilled so we do need to be able to give them simple instructions. Like pasuspender wine <run your program>. Currently this cannot work. So command line options or alter registry manually is not a valid options. Only workable options are auto detection or pulseaudio sets default correct when suspended. Now if pulseaudio and other sound servers were returning default to what it should be the hack of sysdefault in alsa could disappear. Auto detection would become a hack in the wine alsa driver to work around the fact pulseaudio is broken in it suspend system. Its not like using sysdefault is without its own issues if used when pulseaudio is running. Like trying to go around pulseaudio succeeding because hardware has mixing so now fighting with the pulseaudio sound server for access to sound card leading to very bad sounds generated. We don't win here. HW;0 instruction can in fact cause the same problem on some hardware fine used in suspended pulseaudio state but you don't want someone trying that when pulseaudio is running sometimes it will lead to disaster. In fact wine on some systems is breaking pulseaudio because wine is trying sysdefault first at times and when it does not fail processed to uses it while pulseaudio is running so bringing house down. The idea of pasuspender you have stuffed up. You have presumed incorrectly that programs that will have trouble with pulseaudio are after direct hardware access. Not that they are after a system with a fully working alsa setup. Yes to compare driver operations wine needs to see a fully working alsa setup and a fully working pulseaudio one. This way we can compare error messages. and possibly work out where the system went wrong. Basically to prevent wine breaking pulseaudio you need wine to be able to use default dependably. So you can be sure that wine will not try to tunnel under pulseaudio by some means when it should not. Same with other applications you don't want to say hey use HW:0 or use sysdefault were possible due to the fact of where you are leading these applications. You are leading them to breaking the audio system even worse to more driver issues. I know fixing the alsa default to point in the right place is not simple. But telling people to use direct hardware or sysdefault is not good solution. Yes wine we are already seeing problems from both. Due to the breakages this is why the recommendation remove pulseaudio exists if you want to run wine. I wish not to have to provide recommendations to remove pulseaudio. It does many thing well. But one key thing it does poorly is suspend. This is not a new issue all sound servers have this issue so most likely something in alsa has to be corrected to allow it. In fact if you work out how to change alsa configurations on the fly you can prevent all tunnelling under pulseaudio when running. Why you cannot access something when its interface is not displayed. Lacking the means to change configuration on fly causes 2 issues. One pasuspender makes people do unsafe things. Two pulseaudio can be tunnelled under by a alsa application causing problems because people are doing those unsafe things when pulseaudio is running. Wine does not want to be tunnelling under pulseaudio and being blamed for breaking it either. Now a cgroup control of alsa around applications going to pulseaudio blocking those applications from seeing all hardware interfaces other than pulseaudio nicely kills a set of problems. Then another cgroup for applications going straight to hardware. Now the more interesting question then is can a cgroup suspend be used on the applications going straight to hardware to allow a critical audio message from a pulseaudio application to be played. Basically done correctly alsa direct using alsa applications might be just as suspend-able as pulseaudio using applications. All wine wants is alsa audio interfaces that work correctly that will not allow wine to ruin user experiences and allows wine to test what it needs to in comparative testing. Really it should not be asking too much. Better control over what alsa application see will prevent them from doing bad things to pulseaudio. Pulseaudio people think of alsa as low level. Alsa should be thought of as generic interface that should work if its basic rules are obeyed. Problem here is no sound server has made sure they can provide working alsa configurations in every combination. pcm.default does not play sound and mix is a broken for any alsa driver setup. That is what happens under pasuspender so alsa in that mode is broken. -- 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
