Bug 50256

Why do you want to use pasuspender in the first place? Why doesn't Wine work with Pulseaudio?

Tanu Kaskinen
"Why do you want to use pasuspender in the first place? Why doesn't Wine work
with Pulseaudio?"

Main need to use this is to be able to run comparative tests.  Wine usage of audio is not simple.  No comparative tests no isolation exactly where wine is ruining pulseaudio or pulseaudio ruining wine or where wine is exploiting something in alsa that should not be their either.  Making a test needs to be able to prove where and when and what.

Some of this will be hardware related.  Could as simple as wine running pulseaudio out of cpu time on particular hardware combinations.  If suspend and it works isolation that wine is doing something to pulse-audio is achieved.  Not that its that the user has failed to install something in wine so that is why the program is running wrong and doing bad things.  Yes it is possible that application don't alsa.

So something is going wrong if pasuspender works wine can confirm that its audio causing the issue

Tool basically required to answer why.

Secondary is doing asio audio interfaces in wine need jackaudio that also ends up in the pa suspended state to work at times.

So working in a pa suspended state is required at times for wine todo what it needs todo.

Really wine is stuck to run where it needs to could break pulseaudio making the suspended state work as much as wine needs.

For the "default" alsa device to behave differently depending on whether pasuspender is running or not requires either pasuspender to mess with alsa's configuration files, or changing the definition of "default" so that it always checks whether pasuspender is running when it's used. Both are pretty ugly options.

For comparing pulseaudio and direct alsa output in wine, I'd change wine configuration to use some other device than "default" when using alsa directly. Like this:

pasuspender bash
(new shell opens)
wine --audio=alsa:device=hw:0 program.exe
(program.exe is runs and uses hw:0 for audio)
(you close the program and you're back in the shell)
exit
(the new shell exits and pasuspender finishes)

I did not understand why you would use pasuspender with jack, and what changes you need for that to work well. If you're using jack2, then jackd should be able to take over the alsa devices automatically. If you're using jack1, then I'd like to hear a good reason why.

Tanu Kaskinen
"pasuspender bash
(new shell opens)
wine --audio=alsa:device=hw:0 program.exe
(program.exe is runs and uses hw:0 for audio)
(you close the program and you're back in the shell)
exit
(the new shell exits and pasuspender finishes)"
This is not understanding the problem.  hw:0 may or may not include mixing.  If it does not include mixing wine can break and so can applications based off winelib if they are running there own audio based.

So the only device other than default you can use in Alsa only or pasuspender system be sure it has mixing is sysdefault.  hw:0 percentage of users will fail to have operational audio due to the hardware not supporting mixing.

Also --audio flag does not exist on wine.  Audio setting in wine to force a path is registry alteration direct or winecfg http://wiki.winehq.org/UsefulRegistryKeys.

Tanu Kaskinen
"If you're using jack2, then jackd should be
able to take over the alsa devices automatically. If you're using jack1, then
I'd like to hear a good reason why."
http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2
Not really a good reason but some audio people prefer jack1.  We will have to wait until Jack 3 at least for this to be sorted out.

(In reply to comment #4)
> This is not understanding the problem.  hw:0 may or may not include mixing.  If
> it does not include mixing wine can break and so can applications based off
> winelib if they are running there own audio based.
> 
> So the only device other than default you can use in Alsa only or pasuspender
> system be sure it has mixing is sysdefault.  hw:0 percentage of users will fail
> to have operational audio due to the hardware not supporting mixing.

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.

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.

[1] http://www.alsa-project.org/main/index.php/DeviceNames

"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.

(In reply to comment #6)
> 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.

OOM killer should print "pulseaudio invoked oom-killer" to the kernel log if your theory is correct. Have you checked that?

> 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.

I have hard time believing that applications are able to get away with consuming all memory on Windows.

> "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.

Can you point to some documentation?

> 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.

You seem to want to make pasuspender a switcher between "fully functional system with pulseaudio" and "fully functional system without pulseaudio". That's not going to happen. There would be more involved in that than just what the definition of the "default" device is. Implementing all that is not the purpose of pasuspender. Alsa applications have to be explicitly told to use some other device than "default" when using pasuspender. I don't see that ever changing.

> 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.

Really? Typing

    pasuspender wine program.exe

to a terminal is ok, but typing

    pasuspender bash
    wine --audio=alsa:device=sysdefault program.exe

is too hard?

> 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.

No, I'm not encouraging applications to use "hw:0" or "sysdefault". Applications, including wine, should always use "default", unless the user instructs them to do otherwise.

User may need to instruct the application to use e.g. "sysdefault", but ONLY when debugging a problem. Using "sysdefault" or "hw:0" should never be the solution, it's only an intermediate step while trying to figure out what the problem is.

Tanu Kaskinen
"pasuspender bash
    wine --audio=alsa:device=sysdefault program.exe"
--audio is not a flag wine responds to.

--audio=alsa:device=sysdefault  it will try to run --audio=alsa:device=sysdefault.exe in most versions.

Really you have not tried this.  Its functionally not possible to use this solution with the way wine works.

Wine running programs calls multi executables so must be a long term setting there is no valid option command line to alter wine behaviours.  So wine program running a new sub program runs a fresh loader.  This would mean regenerating command-lines and other nightmares leading to command lines too long.

Due to this the only audio overrides are environment variables or registry that people can also leave set.  This is the problem there is no setting with wine that is locked 100 percent for 1 run.  Officially there is no wine environmental var key to alter audio.  Since registry alignment for settings will also be required in places as well to match the new audio setting.

"No, I'm not encouraging applications to use "hw:0" or "sysdefault".
Applications, including wine, should always use "default", unless the user
instructs them to do otherwise."

In fact you are.  Because there is no 100 percent sure way to temp set.  There will never be 100 percent temp way to set with wine.

Reality wine will break pulseaudio if we follow your instructions.  This is not avoidable.

Tanu Kaskinen 
"OOM killer should print "pulseaudio invoked oom-killer" to the kernel log if
your theory is correct. Have you checked that?"
See applicaiton running in wine pulseaudio and many other things with miss behaving programs in wine setting off oom-killer.  But it is less when using dmix.

Tanu Kaskinen
"I have hard time believing that applications are able to get away with
consuming all memory on Windows."
To be correct they don't.  Issue is Linux allows over allocation windows does not.  Lets say hello trouble.   Wine can and does at times create full chaos.

Yes there are reasons why we are looking to cgroups to enforce a few things.

So yes running next to wine you have to expect when things go wrong oomkiller is going to be triggered.

With the mixing
http://www.alsa-project.org/main/index.php/Asoundrc
Then you look at alsa-base all the defined cards.  Yes automatically on any card without mixing default has dmix or equal added.  default always works and always has mixing all bar one case pasuspender.

Tanu Kaskinen
"No, I'm not encouraging applications to use "hw:0" or "sysdefault".
Applications, including wine, should always use "default", unless the user
instructs them to do otherwise."

Yet when user tries to send audio to default in suspended state this errors.  User should not have todo extra instructions.  Extra instructions cause user error.

For wine to be safe we need default to work.  By alsa default should work.

If you cannot disconnect the pulseaudio plugin can you not make it auto forward to sysdefault when suspended  Yes will add some lag but safer since it removes wine having to set setting in it that can stick.  Lot of cases we suspect it wine doing things the sound server part of pulseaudio does not like.

Basically wine need the behaviour of default working.  Default broken wine believes sound broken.  This is a very valid presume.

So to wine people pasuspender is simply busted.  Because real alsa not having a working default is busted.

Tanu Kaskinen
"Alsa applications have to be explicitly told to use some other device than "default" when using pasuspender. I don't see that ever changing."
This is not Alsa this is a Pulseaudio hack.  Because you have not provide a solution to provide a proper working alsa configuration.

Wine will just keep on using sysdefault when it should not be and breaking pulseaudio.   Reality wine is limited on what it can change.   Wine requires something global to refer to for audio settings.  That is not being set right so leading to big problems.

Your complete idea of what applications can do is wrong.  Wine cannot set proper temp setting for audio.  This will never change.  Wine to be safe really needs the globals set correctly.

So the recommendation to remove pulseaudio is right.  There is a fault you will not fix that will forever cause wine trouble.

Does not help that a lot of people using pulseaudio have the wrong idea what pasuspender does.  Lot have the wrong idea it gets them back to raw alsa without pulseaudio.  Not that its a hack.  They come to winehq channel all the time on irc saying they tested with and without pulseaudio.  Guess what they tested with pulseaudio enabled and with pasuspender not without pulseaudio.

So even that the program works perfectly on alsa and due to some bad behavours upsetting pulseaudio they come it us like is fully broken.

Really for wine either fix pcm.default in pasuspender or remove it completely from pulseaudio so you are not driving the wine support channel up wall any more.  If you remove it completely the recommendation to remove pulseaudio will remain.

Fix pcm.default will open the possibility of wine and pulseaudio working with each other.  This is a case wine cannot alter to suit you.  Lot of alterations over the years have been added to the wine alsa driver to suit pulseaudio.

Making default always work one way or the other cannot be too hard.

(In reply to comment #8)
> Tanu Kaskinen
> "pasuspender bash
>     wine --audio=alsa:device=sysdefault program.exe"
> --audio is not a flag wine responds to.
> 
> --audio=alsa:device=sysdefault  it will try to run
> --audio=alsa:device=sysdefault.exe in most versions.
> 
> Really you have not tried this.  Its functionally not possible to use this
> solution with the way wine works.
> 
> Wine running programs calls multi executables so must be a long term setting
> there is no valid option command line to alter wine behaviours.  So wine
> program running a new sub program runs a fresh loader.  This would mean
> regenerating command-lines and other nightmares leading to command lines too
> long.

Ok, I can understand that propagating the command line arguments when forking isn't very nice. An environment variable for configuring the audio backend should still be a viable option, except you say that it isn't:

> Due to this the only audio overrides are environment variables or registry that
> people can also leave set.  This is the problem there is no setting with wine
> that is locked 100 percent for 1 run.  Officially there is no wine
> environmental var key to alter audio.  Since registry alignment for settings
> will also be required in places as well to match the new audio setting.
> 
> "No, I'm not encouraging applications to use "hw:0" or "sysdefault".
> Applications, including wine, should always use "default", unless the user
> instructs them to do otherwise."
> 
> In fact you are.  Because there is no 100 percent sure way to temp set.  There
> will never be 100 percent temp way to set with wine.

Why is it impossible to have an environment variable that has only temporary effect? You say something about "registry alignment" - the windows registry is something that the applications need to function, but wine's sound backend setting do not need to be accessible by applications. Is it so that you're reusing the registry for wine's internal configuration? If that makes it impossible to alter the internal configuration temporarily with environment variables, it sounds like a design mistake... Fixing design mistakes may not be easy, but it doesn't make sense to say that you'll never fix them. Supporting temporary configuration with environment variables makes sense, and not only with audio.

> See applicaiton running in wine pulseaudio and many other things with miss
> behaving programs in wine setting off oom-killer.  But it is less when using
> dmix.

If pulseaudio causes huge amounts of memory use while dmix doesn't, it would be interesting to know what the applications are doing. It might be possible to add some checks to pulseaudio to prevent the excessive memory use.

> Tanu Kaskinen
> "No, I'm not encouraging applications to use "hw:0" or "sysdefault".
> Applications, including wine, should always use "default", unless the user
> instructs them to do otherwise."
> 
> Yet when user tries to send audio to default in suspended state this errors. 
> User should not have todo extra instructions.  Extra instructions cause user
> error.
> 
> For wine to be safe we need default to work.  By alsa default should work.

Yes, and if it doesn't work when "default" is defined to use pulseaudio, it's a bug that needs to be fixed. It should not be just worked around by using pasuspender, but I guess if the user gets the application to work acceptably with pasuspender or by uninstalling pulseaudio, it may often be hard to convince the user to help with debugging the problem further...

> Making default always work one way or the other cannot be too hard.

There are various levels of "working". Making audio "fully work" with pasuspender will probably never be achieved, and it's not the goal either.

That said, I'm starting to think that it does make sense to change the "default" alsa device in pasuspender after all, or at least provide an option for it. I earlier thought that it would require messing with the user's .asoundrc file, which would be a nightmare, but then I realized that actually the alsa library supports the ALSA_CONFIG_PATH environment variable, and it overrides all other alsa configuration files. We can ship an alsa configuration file with pulseaudio that is normally not used for anything, but pasuspender can set ALSA_CONFIG_PATH to point to it. That configuration file would set default to dmix.

Tanu Kaskinen
"Why is it impossible to have an environment variable that has only temporary
effect? You say something about "registry alignment" - the windows registry is
something that the applications need to function, but wine's sound backend
setting do not need to be accessible by applications. Is it so that you're
reusing the registry for wine's internal configuration? If that makes it
impossible to alter the internal configuration temporarily with environment
variables, it sounds like a design mistake... Fixing design mistakes may not be
easy, but it doesn't make sense to say that you'll never fix them. Supporting
temporary configuration with environment variables makes sense, and not only
with audio."

This is two problems.
1) Is dealing with new people.    Wine gets a lot of people new to Linux command line.  So incompetent is not uncommon attempting debugging remotely.

So they do something nasty and evil like "export WINESETTING=<setting>; wine <program>" instead of "WINESETTING=<setting> wine <program>" the second one is temporary first one is stuck in environment.

Yes the first results in a value living on after pasuspender would have been ended to reallow pulseaudio.  So cause us to be yelled at for breaking their pulseaudio.  So if we were setting a environmental var we need to be sure it will be cleaned up when suspend ends.  So any extra environment var is a extra way to drive wine support people up wall if they have to instruct users todo it.

2) windows applications.  They look up for information on hardware from the registry yes wine has to show a device id to applications.

There are two different entries in registry one for voice out and one for general audio out.  Same with input in.  This is required for windows application compatibility.  So changing on fly would look to application that you changed sound card.  This can upset some applications.

Wine tries to keep ids displayed to windows applications inside matching to ids outside wine as much as possible.  Make debugging simpler.

So internal sound output changed to sysdefault from default would cause wine to change id this is fine as long as we don't have a a picky windows program inside.  It a extra variable to debugging why is it busted.  Wine has enough variables without adding any.

Might say don't do this internally but then you have the headache of users who have changed setting to point to stupid locations not turning up in application window screen shots.  Yes level of incompetence wine support people have to deal with its high.  People with less than 8 hours Linux experience turn up in the wine channel.

"I guess if the user gets the application to work acceptably
with pasuspender or by uninstalling pulseaudio, it may often be hard to
convince the user to help with debugging the problem further..."

If it was working acceptably in pasuspender I would be able to get them to debug deeper so it works when pulseaudio is running.  Reason user would not want to stop pulseaudio just to run wine application.  Working acceptably includes not ending up in a location that ruins everything.

You do have them come now complain run pasuspender I have no sound at all in wine and give up and remove pulseaudio.  Yes reason is dead simple wine tried to output to defualt and it does not work.  New users are not always that tolerant.  Basically I need pasuspender to work without users having to play with wine.  Play with wine is proven not to result in good outcomes since new users don't.

Even if users are recording in appdb.winehq.org that this application requires pasuspender to work we still will get a list of applications to investigate to find what they are doing to pulseaudio by the pcm interface.  We could add a universal bug for this and associate all effected applications with it.

Once they have uninstalled pulseaudio the means to get them to debug is completely gone.  Its the need to uninstall I wish to avoid as much as able so progress tracking down where wine and pulseaudio hate each other can be done more successfully.

ALSA_CONFIG_PATH  Is not exactly ideal since this is the global lets change everything.  Ideal would be a ALSA_CONFIGRC_FILE option what would basically be alsalib go read the .asoundrc file but ALSA does not have this option.  Yes one of the reasons why this has been such a pain in ass for so long you can not change the user modification in ALSA by environmental var.

ALSA_CONFIG_PATH option is something global controlled on and off that could be controlled on an off with the suspend.  So avoiding user errors with wine we have happen.  Ok its bad enough when someone installs stuff in the wrong WINEPREFIX because they exported it. But breaking global sound to the desktop is not good for us.

Not exactly sending default to dmix.  You only need to be able to set default to point to sysdefault when suspended.  Then switch it back when not.

Exit suspend with how evil I know wine can be with lost background processes a find and destroy anything connected to the hardware to allow pulseaudio back would also be a wise addition as well.  Its the cleaning up bit is why I have seen this as required as part of the pa suspend and unsuspend process.  Yes allowed to yell long and loud about applications not cleaning up when terminated.

If wine was not a loader like ld.so this problem would not be as hard.  Its the fact wine is a loader is what takes out doing a command line option.

Working well enough to debug with min setting changes to applications is what I am after.  This way you can just switch between the two modes knowing you did not change a thing or screw a thing up.

The biggest problem from wine is the process forking and knowing when to end the changed settings.  The Pulseaudio stop suspend process is the point you know for sure non alsa settings used for pulseaudio can be ended.  This is why wine setting its self runs into problems.  The setting has to align with Pulseaudio state not aligned causes a stack of problems.  Pulseaudio entering suspend is also when you know you should change settings.  So to us it always appears as something that should be part of Pulseaudio since its the bit that knows when it entering suspend and leaving suspend. 

Yes even if it a special option like pasuspender --enable-default  Then at end of suspend remove default change.  I know its been simpler for pulseaudio to push work around default back onto applications.  Problem here wine is not an application.  Wine is an application loader.  Loaders have a very hard time working out when settings should be terminated.

Wine can be connected to binfmt_misc on some systems I missed mentioning this so when in binfmt_misc altering commandline for suspend or not is impossible.  Same headache applies to java and mono and other things that can be placed in binfmt_misc.

Yes so some have been thinking wine is asking for some special alteration that other applications don't need.  This is a case of not seeing wine as the correct class of thing.  Other application loader will gain from pasuspender doing the right thing with default or being able to be told todo the right thing with default.

The fun of being a different class and people the other end not seeing it.

(In reply to comment #10)
> Tanu Kaskinen
> "Why is it impossible to have an environment variable that has only temporary
> effect? You say something about "registry alignment" - the windows registry is
> something that the applications need to function, but wine's sound backend
> setting do not need to be accessible by applications. Is it so that you're
> reusing the registry for wine's internal configuration? If that makes it
> impossible to alter the internal configuration temporarily with environment
> variables, it sounds like a design mistake... Fixing design mistakes may not be
> easy, but it doesn't make sense to say that you'll never fix them. Supporting
> temporary configuration with environment variables makes sense, and not only
> with audio."
> 
> This is two problems.
> 1) Is dealing with new people.    Wine gets a lot of people new to Linux
> command line.  So incompetent is not uncommon attempting debugging remotely.
> 
> So they do something nasty and evil like "export WINESETTING=<setting>; wine
> <program>" instead of "WINESETTING=<setting> wine <program>" the second one is
> temporary first one is stuck in environment.
> 
> Yes the first results in a value living on after pasuspender would have been
> ended to reallow pulseaudio.  So cause us to be yelled at for breaking their
> pulseaudio.  So if we were setting a environmental var we need to be sure it
> will be cleaned up when suspend ends.  So any extra environment var is a extra
> way to drive wine support people up wall if they have to instruct users todo
> it.

Users will copy-paste what you tell them to copy-paste. If you don't mention the "export" command, they won't even know that such command exists.

> 2) windows applications.  They look up for information on hardware from the
> registry yes wine has to show a device id to applications.
> 
> There are two different entries in registry one for voice out and one for
> general audio out.  Same with input in.  This is required for windows
> application compatibility.  So changing on fly would look to application that
> you changed sound card.  This can upset some applications.

Changing on the fly? What? You don't change the environment variable while the application is running.

> ALSA_CONFIG_PATH  Is not exactly ideal since this is the global lets change
> everything.  Ideal would be a ALSA_CONFIGRC_FILE option what would basically be
> alsalib go read the .asoundrc file but ALSA does not have this option.  Yes one
> of the reasons why this has been such a pain in ass for so long you can not
> change the user modification in ALSA by environmental var.
> 
> ALSA_CONFIG_PATH option is something global controlled on and off that could be
> controlled on an off with the suspend.  So avoiding user errors with wine we
> have happen.  Ok its bad enough when someone installs stuff in the wrong
> WINEPREFIX because they exported it. But breaking global sound to the desktop
> is not good for us.

I'm not sure if you understood what I meant. It sounds like you think that I was suggesting that the user would set ALSA_CONFIG_PATH himself. I didn't mean that. pasuspender would set the environment variable, and it would only affect the process (and its children) that is started by pasuspender. The user wouldn't even know, without reading pasuspender man page, that ALSA_CONFIG_PATH is being set.

> Not exactly sending default to dmix.  You only need to be able to set default
> to point to sysdefault when suspended.  Then switch it back when not.

So sysdefault is better than dmix? Ok, fine.

> If wine was not a loader like ld.so this problem would not be as hard.  Its the
> fact wine is a loader is what takes out doing a command line option.
> 
> Working well enough to debug with min setting changes to applications is what I
> am after.  This way you can just switch between the two modes knowing you did
> not change a thing or screw a thing up.
> 
> The biggest problem from wine is the process forking and knowing when to end
> the changed settings.  The Pulseaudio stop suspend process is the point you
> know for sure non alsa settings used for pulseaudio can be ended.  This is why
> wine setting its self runs into problems.  The setting has to align with
> Pulseaudio state not aligned causes a stack of problems.  Pulseaudio entering
> suspend is also when you know you should change settings.  So to us it always
> appears as something that should be part of Pulseaudio since its the bit that
> knows when it entering suspend and leaving suspend. 
> 
> Yes even if it a special option like pasuspender --enable-default  Then at end
> of suspend remove default change.  I know its been simpler for pulseaudio to
> push work around default back onto applications.  Problem here wine is not an
> application.  Wine is an application loader.  Loaders have a very hard time
> working out when settings should be terminated.
> 
> Wine can be connected to binfmt_misc on some systems I missed mentioning this
> so when in binfmt_misc altering commandline for suspend or not is impossible. 
> Same headache applies to java and mono and other things that can be placed in
> binfmt_misc.

I don't think this aspect is very relevant here. When you use pasuspender, you'll have to run it like "pasuspender -- wine program.exe" (or I guess "pasuspender -- program.exe" works too).

If I understood correctly, you'd like to just run "pasuspender suspend" or something like that, and the system would enter to direct alsa mode, and "pasuspender unsuspend" would return to normal pulseaudio mode. I don't think that's doable. I believe that there's no sane way for changing the global settings safely, let alone changing the audio mode of already-running applications.

Tanu Kaskinen
"Changing on the fly? What? You don't change the environment variable while the
application is running."

Ok you don't know wine.  We change settings from environment variables while sections of wine are still running.  So yes we do have on fly changes in settings.

Reality wineserver can be still running in background.  So yes with wine changing a environment var does trigger at times change on fly.  There is one wineserver instance per wine prefix.  So if user is running more than one application from that prefix like one that will work in pa that suspends it output.  Then one is run pasuspender wine application.  Welcome to mid air collision.

Registry in the prefix is accessed by wineserver.  All registry access in a prefix go threw the wineserver owning to that prefix.  This can remain running after application terminates.

Yes wine is not your normal application.  It has services.  Those services have to be synced with what is going on.  This is why wine change audio settings or any other setting on fly becomes a major problem at times particularly if they are not going to be compatible.  While PA is suspended wine applications could be referring to the wine registry of application running under PA or worse applications running under PA pulling settings from registry that have been altered to support suspended state.

This is also why export is used on a few environment vars with wine since some wine will pickup on fly.

pasuspender -- program.exe  can be true if binfmt-misc is set.

Yes thinking that wine is a normal program is causing problem here.  Idea that you could simply just override something does not exist with wine.   Wine needs to be able to have the same audio settings when pulseaudio is running and when its suspended.  Otherwise you are playing with altering settings on a running system and hope it don't destroy something.

Wine is lucky that the alsa lookups are loader side not service/daemon side.  But configuration data is in registry because it has to be.

"I believe that there's no sane way for changing the global
settings safely, let alone changing the audio mode of already-running
applications."
This is what we have to pull off with wine to be windows compatible.

Yes it would be possible to connect wine sound system to a system wide service to be notified of a audio change and have wine alter to suit without applications using wine being too upset most of the time.  But no such global service to notify applications of alsa setting changes exist.

So yes its possible with a little work on the wine alsa driver to keep on outputting sound while pulseaudio is suspended and to returned to pulseaudio when suspend ends.  That is of course if there is some from of framework to inform wine what is going on.

Wine has emulated windows means to change sound card on fly fairly well not as complete as it could be.

So when it comes to wine changing audio mode of a running application would fall into camp of annoyance.  Do able by what wine has had to implement but nothing exists globally to inform wine of changes.  Yes this is a weakness of alsa.  Alsa retakes it configuration every time it runs.  But no one include a service to inform applications of change settings now.  It would be surprising how powerful Alsa could come just with something to manage its settings and to allow setting changes on fly.

Tanu Kaskinen
"So sysdefault is better than dmix? Ok, fine."
sysdefault has any extra setting the hardware needs to operate.  Where plan dmix might try sending the wrong speed or width audio to the device.  So yes better.

Tanu Kaskinen
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5589

Maybe this is a case we need to update alsalib to allow configuration changes on fly.  This could possibility move the problem out either of our ways.

Really lot of the problem here is alsa has poor hotplug support.   Alsa with good hotplug support would be a lot more friendly of a beast.

Making alsa work right in a lot of ways is better than having every application with pulseaudio drivers and alsa drivers.   Since it could now allow application to change audio servers on fly as well.

This hotplug in alsa support would end lot of the audio disputes.  Again this provides wine with something it can refer to outside itself that should be always right.

Do what I am suggesting with Alsa and then pulseaudio could fully stop and give back raw alsa and raw alsa applications could let go of alsa to let pulseaudio take over same with any other sound server.  Also possibly doing in the need for pasuspender.  Ok pulseaudio applications pulseaudio has vamoosed stay in holding pattern until pulseaudio comes back.

One ABI for audio that works no matter the configure is idea.  ALSA is a little hard to remove.

Mostly its like the pulseaudio jackaudio dbus handshaken over alsa.   Except you do this generically in alsalib effecting all alsa applications.   So it might be a case of right idea done at wrong level.

(In reply to comment #12)
> Tanu Kaskinen
> "Changing on the fly? What? You don't change the environment variable while the
> application is running."
> 
> Ok you don't know wine.  We change settings from environment variables while
> sections of wine are still running.  So yes we do have on fly changes in
> settings.
> 
> Reality wineserver can be still running in background.  So yes with wine
> changing a environment var does trigger at times change on fly.  There is one
> wineserver instance per wine prefix.  So if user is running more than one
> application from that prefix like one that will work in pa that suspends it
> output.  Then one is run pasuspender wine application.  Welcome to mid air
> collision.
> 
> Registry in the prefix is accessed by wineserver.  All registry access in a
> prefix go threw the wineserver owning to that prefix.  This can remain running
> after application terminates.
> 
> Yes wine is not your normal application.  It has services.  Those services have
> to be synced with what is going on.  This is why wine change audio settings or
> any other setting on fly becomes a major problem at times particularly if they
> are not going to be compatible.  While PA is suspended wine applications could
> be referring to the wine registry of application running under PA or worse
> applications running under PA pulling settings from registry that have been
> altered to support suspended state.

Ok, so is the model that the first "wine" command invocation with a given prefix will start also wineserver, and the wineserver process will be running as long as there are wine processes using that prefix? And the audio backend configuration affects the shared registry, because it's useful to see the backend configuration from the windows application screenshots.

Given that setup, I now understand why the wine program indeed shouldn't take the audio backend configuration from an environment variable. Wineserver could still use the environment variable, but that complicates the instructions that you would need to give to the user when running pasuspender:

First, close all wine applications ("killall wine").
Then, run "WINE_AUDIO=alsa{device=sysdefault} pasuspender -- wine program.exe".

Closing all wine applications first should ensure that the pasuspender command will launch a fresh wineserver too, so the environment variable will have effect. One side effect of this would be that "wine" should now query the audio backend setting from "wineserver". (Or maybe it already does that anyway?)

If you think that would be useful, you could also write a graphical launcher program for debugging, which would remove some of the complexity for the user. The program could set the audio backend environment variable, kill all existing wine processes (maybe with a "are you sure" dialog), and run the selected application under pasuspender.

That said, I think adding the ALSA_CONFIG_PATH feature to pasuspender would work better, because with that solution you don't have the problem that the setting needs to be shared between wine processes. I didn't quite understand what the problem with ALSA_CONFIG_PATH was that you tried to describe. You talked something about it being "global", but I didn't understand what you meant. Could you elaborate?

Tanu Kaskinen
"Ok, so is the model that the first "wine" command invocation with a given
prefix will start also wineserver, and the wineserver process will be running
as long as there are wine processes using that prefix?"
Yes this is close to correct for the current model.  Wineserver stays running after the last application stops in a prefix for a while.  Some things are stored in this like current font lists and other time consuming thing to set up.

Note I say current.  Future model of wine does include the possibility of global wineservers existing.  Reason wine prefixes with applications shared between users.  When this happens the problem will become many times worse.  No more option for a single user to be sure to shut everything down to enter pasuspender.  This is why upstream does not particularly like the idea of  "Wineserver could still use the environment variable".

First, close all wine applications ("killall wine").  This in wine is wineserver -k.  Yes this shows how much in control wineserver is you tell it to die and every other wine application dies.

"WINE_AUDIO=alsa{device=sysdefault} pasuspender -- wine program.exe"
This is also not going to work.

wine program.exe;wineserver -k would have to be used.  Otherwise wineserver would still be alive after pasuspender so land mined.  Remembering the environmental var it was told.

This is the problem with wine it really does not like you trying todo temporary changes from environmental var or command line.  Really hates change.  wineserver -k itself is not exactly nice on windows applications either.

ALSA_CONFIG_PATH really I would prefer to avoid touching this if we can.

Opps I moused clicked at the wrong time.

ALSA_CONFIG_PATH really I would prefer to avoid touching this if we can.  Historically its been the universal way to stomp on ALSA to make it do what you wish.   But that does not really make it right.

If someone has hardware issues and they are wanting to test that out they might have intentionally set ALSA_CONFIG_PATH to alter how Alsa inits up.

Now we have the idea go and override this is this wise.  Each environmental var should have a role.   Currently its abused  ALSA_CONFIG_PATH global hardware defines is in the alsa.conf files.  Temp overrides should exist as a different environmental option.  This would make life so many times simpler. 

The bending of ALSA_CONFIG_PATH tracks to stacks and stacks of historic stuff ups.   The .asoundrc was always intended for those more temporary settings.  Problem was we were never given a environmental var to push it around.

So hardware setting and temp settings are getting bashed around by one environmental var this does explain why it goes so badly wrong.

Wine has global defines like the base if it default registry.  This is read every time a prefix is created.   Then we have more localised configurations contained to the WINEPREFIX.

So my use of global is exactly correct.  Its more way of thinking about what you should and not be playing with.   Playing with wine registry master template location of wine registry is not the correct way to address a application problem.

This case we have a single application we are trying to fix yet we are moving the look up location to configure sound cards and hoping the one we point to points back to the correct one.  This spells trouble to me.

If a alsa envormental var existed for pulseaudio, jackaudio and any other audio server or per application alterations of sound config so avoiding touching ALSA_CONFIG_PATH that contains information to setup hardware at times.  Failures would be reduced.

"ALSA_CONFIG_PATH 
    file to use instead of ALSA_CONFIG_DIR/alsa.conf" 
ALSA_MIXER_SIMPLE 
    file to use instead of ALSA_CONFIG_DIR/smixer.conf 
ALSA_MIXER_SIMPLE_MODULES 
    path to modules .so files"
Nothing currently provided is correct for the problem at hand.

You say it would be hard to do a full alsa as if untouched in pasuspender.  Reality this is only because of lack of clear separation of roles in the environmental vars.

If sound server settings were not mixed with hardware configuration information in alsa.conf existing back to a pure alsa would be very straight forwards.

Like if a ALSA_ASOUNDRC_FILE option existed in the library or ALSA_SOUNDSERVER_FILE existed in the library for extra settings and sound servers used this.  That file would contain like all your pulseaudio setup stuff.  So remove then remove var and magically alsa application would init up like pulseaudio is not running as long as pulseaudio had disconnected from the audio.

Yes the reality is alsa was designed to be able to change configuration at lot.  But someone presumed that users would only need one configuration file so never made .asoundrc environmental var settable.

Wine without its WINEPREFIX environmental var would be the same problem.  For us this would be 100 percent unworkable and we cannot understand why audio guys keep on trying to place all settings in the one alsa.conf files.  Then complain things get hard.  Not seeing that the problem is not having a single extra environmental var you need.

Remember when ALSA started ALSA_CONFIG_PATH did not exist either it was hard coded into the library.  Current ~/.asoundrc is hard coded this is the file that should contain all the users own unique configuration changes.  Sound server should be in .asoundrc somehow.  Most likely as a environment var telling applications where to look .asoundrc up from.  This also would have allowed wine to work around the pulseaudio suspender issue.  Hey read this .asoundrc file that corrects default to point somewhere sane.

When something is hard coded when it should not be leaded to doing stacks of painful operations to oneself without any sane need.  This is why pulseaudio has such a hard time dropping back to alsa without pulseaudio.

(In reply to comment #16)
> If someone has hardware issues and they are wanting to test that out they might
> have intentionally set ALSA_CONFIG_PATH to alter how Alsa inits up.

I think the --redefine-alsa-default-pcm={yes,no} parameter should behave so that if it's not given at all, then ALSA_CONFIG_PATH is set, unless it's already set. Explicitly giving --redefine-alsa-default-pcm would set ALSA_CONFIG_PATH even if it's already set. That should cover the 1% of cases where the user actually has set ALSA_CONFIG_PATH himself.

> Now we have the idea go and override this is this wise.  Each environmental var
> should have a role.   Currently its abused  ALSA_CONFIG_PATH global hardware
> defines is in the alsa.conf files.  Temp overrides should exist as a different
> environmental option.  This would make life so many times simpler. 

It's not terribly complicated to load /usr/share/alsa/alsa.conf in the beginning of the custom configuration file...

> The bending of ALSA_CONFIG_PATH tracks to stacks and stacks of historic stuff
> ups.   The .asoundrc was always intended for those more temporary settings. 
> Problem was we were never given a environmental var to push it around.

I'd imagine that ~/.asoundrc is not primarily for temporary changes (of course it can be used for that too). ~/.asoundrc is useful for permanent user-specific configuration.

> So hardware setting and temp settings are getting bashed around by one
> environmental var this does explain why it goes so badly wrong.
> 
> Wine has global defines like the base if it default registry.  This is read
> every time a prefix is created.   Then we have more localised configurations
> contained to the WINEPREFIX.
> 
> So my use of global is exactly correct.  Its more way of thinking about what
> you should and not be playing with.   Playing with wine registry master
> template location of wine registry is not the correct way to address a
> application problem.
> 
> This case we have a single application we are trying to fix yet we are moving
> the look up location to configure sound cards and hoping the one we point to
> points back to the correct one.  This spells trouble to me.

I don't see the problem. Just make sure that the base configuration is loaded from the custom configuration file.

> If a alsa envormental var existed for pulseaudio, jackaudio and any other audio
> server or per application alterations of sound config so avoiding touching
> ALSA_CONFIG_PATH that contains information to setup hardware at times. 
> Failures would be reduced.
> 
> "ALSA_CONFIG_PATH 
>     file to use instead of ALSA_CONFIG_DIR/alsa.conf" 
> ALSA_MIXER_SIMPLE 
>     file to use instead of ALSA_CONFIG_DIR/smixer.conf 
> ALSA_MIXER_SIMPLE_MODULES 
>     path to modules .so files"
> Nothing currently provided is correct for the problem at hand.

It sounds like you are talking about some other problems than the one at hand. Or at least to me ALSA_CONFIG_PATH seems perfectly usable for redefining pcm.default as pcm.sysdefault.

> You say it would be hard to do a full alsa as if untouched in pasuspender. 
> Reality this is only because of lack of clear separation of roles in the
> environmental vars.
> 
> If sound server settings were not mixed with hardware configuration information
> in alsa.conf existing back to a pure alsa would be very straight forwards.
> 
> Like if a ALSA_ASOUNDRC_FILE option existed in the library or
> ALSA_SOUNDSERVER_FILE existed in the library for extra settings and sound
> servers used this.  That file would contain like all your pulseaudio setup
> stuff.  So remove then remove var and magically alsa application would init up
> like pulseaudio is not running as long as pulseaudio had disconnected from the
> audio.

This sounds like you'd want ALSA_SOUNDSERVER_FILE to be always set when using Pulseaudio. I think that's a bad idea. Managing this kind of session-wide environment variables is very user-unfriendly, and an additional problem is that there is no single standard file where per-user environment variables can reliably be stored (at least it used to be so that terminal sessions and X sessions had completely separate initialization scripts, and even different desktop environments used different scripts, so there was no central file to put environment variables that should be set regardless of the session type). Maybe I misunderstood what you were suggesting?

Also, it indeed needs "magic" to remove a session-wide environment variable. Without magic, a relogin is needed, which is not very cool.

> Yes the reality is alsa was designed to be able to change configuration at lot.
>  But someone presumed that users would only need one configuration file so
> never made .asoundrc environmental var settable.
> 
> Wine without its WINEPREFIX environmental var would be the same problem.  For
> us this would be 100 percent unworkable and we cannot understand why audio guys
> keep on trying to place all settings in the one alsa.conf files.

You could explicitly load the master template from the prefix configurations. That should work equally well as your current situation. I'm not arguing that it would be a better option for you, only that it would be workable.

>  Then complain
> things get hard.  Not seeing that the problem is not having a single extra
> environmental var you need.

I have failed to understand what problem extra environment variables would solve.

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.

(In reply to comment #18)
> So might as well abuse ALSA_CONFIG_PATH for now.  Because it will make this
> problem work for now.

We have an agreement here then. Thank you. I have a patch for pasuspender that implements this feature, but I have trouble with the alsa configuration file contents. I sent a message[1] about it to alsa-devel. Are you able to help with this, perhaps?

Regarding the rest of your message, I don't consider the problems that you described very serious. But if you want to redesign alsa, feel free to do so...

[1] http://thread.gmane.org/gmane.linux.alsa.devel/98323

Tanu Kaskinen had a look at the files.

Don't have pulseaudio installed but please try something.  I am on debian.

Duplicate /usr/share/alsa/alsa.conf and from the duplicate remove alsa.conf.d import reference.

I am fairly sure this will cause normal alsa to fire up without pulse as default.

I might have thought of another way to skin the cat.  Can we make pulse alsa pcm completely fail when suspended.  So that while suspended alsa spins threw its detection its the pulse alsa pcm and it simply fails like if pulseaudio is not running at all when suspended.  This might be enough to send alsa back to setting itself with default working again.

The issue might be that pulse pcm interface is not failing bad enough so alsa ends up in a bad state because it thinks the pulse pcm is a working interface when its not.

In one way you could say that pulseaudio is perfectly emulating broken sound card in its current suspended mode.  The look of default pointing to something that does not work is exactly what you expect a broken sound card that will not put out on alsa todo.  Basically get the pcm plugin to follow the code path it does when it does not detect pulseaudio.

That might magically get to the state that suspended is exactly like pulseaudio is not running.  It all could be a minor case of pulseaudio not emulating a sound card well enough.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/128.