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

Tue Jun 5 01:49:01 PDT 2012

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

--- Comment #12 from oiaohm at gmail.com 2012-06-05 01:49:01 PDT ---
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.

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