You probably want to set

XDG_CONFIG_HOME to point to ~/.xdg/config (instead of the default ~/.config)

See also:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

I already have, in two ways.

$ head -3 /etc/profile.d/custom.sh
export XDG_CONFIG_HOME="${HOME}/.xdg/config"
export XDG_DATA_HOME="${HOME}/.xdg/data"
export XDG_CACHE_HOME="${HOME}/.xdg/cache"
$ cat .pam_environment 
XDG_CACHE_HOME          DEFAULT=/home/carl/.xdg/cache
XDG_CONFIG_HOME         DEFAULT=/home/carl/.xdg/config
XDG_DATA_HOME           DEFAULT=/home/carl/.xdg/data

That what is making this frustrating, because this pulse cookie is the only thing on my system that is in ~/.config.  I keep deleting the directory, but it keeps getting recreated.  Every other program either respects XDG_CONFIG_HOME, or has its own ~/.appname directory (such as .ssh, .java, etc).

libpulse needs to either properly respect XDG_CONFIG_HOME, or respect its own PULSE_COOKIE variable.

setting PULSE_COOKIE works for me.

I tested using pulseaudio-4.0-9.gitf81e3.fc20.x86_64  on fedora 20, put this into my ~/.bashrc:

export PULSE_COOKIE=$HOME/.xdg/config/pulse/cookie
and restarted my (kde) session, and that cookie file got used/updated.


But... indeed it does not seem to respect XDG_CONFIG_HOME.

I installed the rest of pulseaudio on my Arch laptop to test this further.

$ pacman -Q pulseaudio pulseaudio-alsa libpulse paprefs pavucontrol
pulseaudio 4.0-6
pulseaudio-alsa 2-2
libpulse 4.0-6
paprefs 0.9.10-2
pavucontrol 2.0-2

After doing this, I found that simply launching pavucontrol will demonstrate the problem.  PULSE_COOKIE is still set, but two cookies are created.

$ echo ${PULSE_COOKIE}
/home/carl/.xdg/config/pulse/cookie
$ ls -l ~/.{xdg/,}config/pulse/cookie
ls: cannot access /home/carl/.xdg/config/pulse/cookie: No such file or directory
ls: cannot access /home/carl/.config/pulse/cookie: No such file or directory
$ pavucontrol &> /dev/null &
[1] 1075
$ ls -l ~/.{xdg/,}config/pulse/cookie
-rw------- 1 carl carl 256 Feb 20 22:05 /home/carl/.config/pulse/cookie
-rw------- 1 carl carl 256 Feb 20 22:05 /home/carl/.xdg/config/pulse/cookie

I tested pulseaudio 4.99.3 on Windows XP 32-bit SP3 Pro:

PULSE_COOKIE is ignored. 

It does not matter whether the parent directory exists or not. I made sure to specify a path under a directory that I have permissions to write to, and that contains no spaces. For example, I tried:
set PULSE_COOKIE=C:\test\cookie

XDG_CONFIG_HOME - This variable is respected, however there is a different bug present. I wrote this bug up as:
Bug 75418 - Cookie not created & PA may not start when XDG_CONFIG_HOME is set on Windows 
https://bugs.freedesktop.org/show_bug.cgi?id=75418

I'm working on this. The changes that I plan to do are not small, and I have limited time to work on this, which is why the fix may take some time. For the same reason the fix might not go in 5.0.

I want this fixed in 6.0, so I made this now a release blocker bug.

I'll attach a couple of patches that should fix the issue that multiple cookie are created if PULSE_COOKIE is set. I'll keep working on the issue that XDG_CONFIG_HOME is not respected.

Michael, it occurred to me that you may be expecting that PULSE_COOKIE would affect the server. I believe it doesn't. Maybe it should, but mainly the environment variable is meant for clients. On the server side, you can pass the auth_cookie argument to module-protocol-native-tcp in default.pa.

If you run e.g. "pactl info" in an environment where PULSE_COOKIE is set, then the cookie should be created at the location pointed to by PULSE_COOKIE (but if the server isn't configured to use the same cookie file, authentication will fail).

Created attachment 96033 [details] [review]
Multiple cookie files fix 1/2

Created attachment 96034 [details] [review]
Multiple cookie files fix 2/2

Thank you Tanu for your work on this.  If the XDG_CONFIG_HOME bug is fixed, I won't even need to set PULSE_COOKIE, so this is great news.

Another alternative that I wouldn't mind would be moving the default cookie file location to /run/user/${UID}/pulse/cookie.

The cookie needs to be persistent to manage authentication across multiple machines.

Thank you very much Tanu.

X2Go Client 4.0.2.0 is about to be released. I've already committed the code to X2Go Client so that the "auth-cookie" argument is passed to module-native-protocol-tcp on Windows. This approach meets our needs.

For reference (the bug report is very long), I documented this change at the end of this X2Go Client bug report
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422

Also, I apologize. I should have read the pulseaudio (1) manpage more closely. It does state that the PulseAudio client libraries respect $PULSE_COOKIE, not the PulseAudio daemon.

Nice to hear that you got your problem solved!

As for the original XDG_CONFIG_HOME bug that I was supposed to fix, there has been no progress due to lack of time. Hopefully I'll find some time this week, but no promises.

I submitted patches that should finally fix the remaining issues: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/20486

@Tanu Thanks, I'll test them on my win32 builds as soon as I can.

@Tanu, please hold off on committing the 9 patches for now.

Currently we (x2goclient master branch) are telling pulseaudio win32 to load a config.pa script with the following lines (the only thing that ever varies is the port):
load-module module-native-protocol-tcp port=4713 auth-cookie=\.pulse-cookie
load-module module-esound-protocol-tcp port=4714
load-module module-waveout

And we have %USERPROFILE% set to a value such as:
C:\Users\MIKE~1.DEP\X2GO~1\pulse

We have neither XDG_CONFIG_HOME or PULSE_COOKIE set.

With 5.0-121-g38c5d without the 9 patches applied, the following intended cookie is used, and X2Go Client works with PulseAudio:
C:\Users\mike.DEPAULO\.x2go\pulse\.pulse-cookie
debug log: http://pastebin.com/ptFAwJQ6

When I apply all 9 patches (5.0-121-g38c5d-dirty), that cookie is not used. Instead, the following cookie is created (and presumably used):
C:\Users\mike.DEPAULO\.x2go\pulse\.config\pulse
debug log: http://pastebin.com/Y2Ke2rk7
Since we copy the other cookie to the X2Go Server, audio does not work.

I will try to fix this compatibility issue by defining %PULSE_COOKIE% and/or %XDG_CONFIG_HOME% in the x2goclient master branch code that launches (and sets the environment for) pulseaudio.exe. I'll let you know how it goes.

The patches change the search path for relative cookie paths from $(HOME) to $(XDG_CONFIG_HOME)/pulse or $(HOME)/.config/pulse, depending on whether XDG_CONFIG_HOME is set or not. So if you use "auth_key=.pulse-cookie", the resulting path is $(HOME)/.config/pulse/.pulse-cookie. This is an intentional and necessary change.

Is there a reason why you must use $(HOME)/.pulse-cookie?

Typo in the previous comment: "auth_key" was supposed to be "auth-cookie".

@Tanu Our intention is for our users to be able to downgrade/upgrade to another version of X2Go Client for Windows without being told to delete their existing cookie. We may also release the current version of X2Go Client with an older version of PulseAudio if a regression is found (until I came along and upgraded our bundled version of PulseAudio to 5.0, we shipped both 1.1 and 0.9.6 via separate x2goclient installers.)

Anyway, I'll try specifying an absolute path to .pulse-cookie in before I try setting XDG_CONFIG_HOME. I'll probably have this figured out within a few days.

What if you don't set the auth-cookie parameter at all? We still have code that checks the legacy cookie location, i.e. $(HOME)/.pulse-cookie if nothing else is configured.

It wouldn't be out of question to extend the legacy location handling also for configured relative paths. Maybe I should do that...

Hi Tanu,

1st, note that on Windows, %USERPROFILE% is the replacement for $(HOME). Submit complaints to 1 Microsoft Way...

2nd, remember that X2Go users might downgrade their PulseAudio version on Windows. We have supported PulseAudio downgrades on Windows. So both .pulse-cookie and .config/pulse/cookie might exist when PulseAudio 1.1 is installed.

When we did not set auth-cookie at all, if the following conditions were met, PulseAudio failed to create the cookie and therefore failed to start:
1. PulseAudio 3.0 & later on Windows
2. PA was launched by X2Go Client, rather than from the command line.
3. Neither ".pulse-cookie", ".config/pulse/cookie" or ".config/pulse/" existed.
It took me a long time to figure out that we could fix the issue by creating the empty dir ".config/pulse/". We considered just creating said empty dir, but we talked with you and decided on specifying auth-cookie instead. We only specify auth-cookie if PulseAudio 3.0 or later is installed. We check the version by running "pulseaudio.exe --version" and then reading the stdout.
This is a long bug report, but I documented it here:
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422

I might have fixed said issue (condition #2) with x2goclient commit 6d3998f6:
Windows: Fix compatibility with current PulseAudio master branch by replacing forward shashes with backslashes in file/folder paths.
(Yes, I made a typo in the commit message.)
That commit was actually necessary for the current PA master branch to work with x2goclient. The fact that we had specified %USERPROFILE% as an 8.3 filepath with forward slashes seemed like a bug in our code, so I changed it to an 8.3 filepath with backslashes. I tested the change with master, 5.0, and old versions of PulseAudio, and then committed it to our code.

Anyway, I need to do some actual testing. (My weekend is coming up, so I have time available.) If said commit fixed the issue with cookie creation on versions 3.0 through 5.0, then I could update x2goclient code to upload the correct cookie depending upon which version of PulseAudio is installed. However, it seems like less work for me to just specify an absolute cookie path, or to specify %XDG_CONFIG_HOME%.

(In reply to comment #23)
> Hi Tanu,
> 
> 1st, note that on Windows, %USERPROFILE% is the replacement for $(HOME).
> Submit complaints to 1 Microsoft Way...

Sure, I use $(HOME) just as a shorthand. %USERPROFILE% is handled fine.

> 2nd, remember that X2Go users might downgrade their PulseAudio version on
> Windows. We have supported PulseAudio downgrades on Windows. So both
> .pulse-cookie and .config/pulse/cookie might exist when PulseAudio 1.1 is
> installed.

This should be no problem, if after the downgrade both the server and the clients are using the same version of libpulse. As long as the server and the clients use the same logic for finding the cookie, things should work.

> When we did not set auth-cookie at all, if the following conditions were
> met, PulseAudio failed to create the cookie and therefore failed to start:
> 1. PulseAudio 3.0 & later on Windows
> 2. PA was launched by X2Go Client, rather than from the command line.
> 3. Neither ".pulse-cookie", ".config/pulse/cookie" or ".config/pulse/"
> existed.
> It took me a long time to figure out that we could fix the issue by creating
> the empty dir ".config/pulse/". We considered just creating said empty dir,
> but we talked with you and decided on specifying auth-cookie instead. We
> only specify auth-cookie if PulseAudio 3.0 or later is installed. We check
> the version by running "pulseaudio.exe --version" and then reading the
> stdout.
> This is a long bug report, but I documented it here:
> http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
> 
> I might have fixed said issue (condition #2) with x2goclient commit 6d3998f6:
> Windows: Fix compatibility with current PulseAudio master branch by
> replacing forward shashes with backslashes in file/folder paths.
> (Yes, I made a typo in the commit message.)
> That commit was actually necessary for the current PA master branch to work
> with x2goclient. The fact that we had specified %USERPROFILE% as an 8.3
> filepath with forward slashes seemed like a bug in our code, so I changed it
> to an 8.3 filepath with backslashes. I tested the change with master, 5.0,
> and old versions of PulseAudio, and then committed it to our code.

PulseAudio should create the necessary directories if they don't exist. The slash issue indeed sounds like a probable cause for the directory creation failure.

> Anyway, I need to do some actual testing. (My weekend is coming up, so I
> have time available.) If said commit fixed the issue with cookie creation on
> versions 3.0 through 5.0, then I could update x2goclient code to upload the
> correct cookie depending upon which version of PulseAudio is installed.
> However, it seems like less work for me to just specify an absolute cookie
> path, or to specify %XDG_CONFIG_HOME%.

Setting XDG_CONFIG_HOME is probably not a good idea. If I understood correctly, you'd set USERPROFILE to "C:\Users\mike.DEPAULO\.x2go\pulse" and XDG_CONFIG_HOME to "C:\Users\mike.DEPAULO\.x2go". That probably works, but doesn't make sense conceptually. It would be similar to setting XDG_CONFIG_HOME on Linux to /home, and assuming that the user name is "pulse".

(In reply to comment #24)
> (In reply to comment #23)
> > Hi Tanu, 
> > 2nd, remember that X2Go users might downgrade their PulseAudio version on
> > Windows. We have supported PulseAudio downgrades on Windows. So both
> > .pulse-cookie and .config/pulse/cookie might exist when PulseAudio 1.1 is
> > installed.
> 
> This should be no problem, if after the downgrade both the server and the
> clients are using the same version of libpulse. As long as the server and
> the clients use the same logic for finding the cookie, things should work.
> 
Actually, we have been making PulseAudio servers and clients talk to eachother even when they have very different versions of libpulse. For example, Ubuntu 10.04 has libpulsecore-0.9.21.so (although the 10.04 package version number is supposedly 0.9.22), while Ubuntu 14.04 has libpulsecore-4.0.so. Yet having those 2 machines talk to eachother is something we support with X2Go.

Let's discuss that in a separate email thread though.

> > When we did not set auth-cookie at all, if the following conditions were
> > met, PulseAudio failed to create the cookie and therefore failed to start:
> > 1. PulseAudio 3.0 & later on Windows
> > 2. PA was launched by X2Go Client, rather than from the command line.
> > 3. Neither ".pulse-cookie", ".config/pulse/cookie" or ".config/pulse/"
> > existed.
> > It took me a long time to figure out that we could fix the issue by creating
> > the empty dir ".config/pulse/". We considered just creating said empty dir,
> > but we talked with you and decided on specifying auth-cookie instead. We
> > only specify auth-cookie if PulseAudio 3.0 or later is installed. We check
> > the version by running "pulseaudio.exe --version" and then reading the
> > stdout.
> > This is a long bug report, but I documented it here:
> > http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=422
> > 
> > I might have fixed said issue (condition #2) with x2goclient commit 6d3998f6:
> > Windows: Fix compatibility with current PulseAudio master branch by
> > replacing forward shashes with backslashes in file/folder paths.
> > (Yes, I made a typo in the commit message.)
> > That commit was actually necessary for the current PA master branch to work
> > with x2goclient. The fact that we had specified %USERPROFILE% as an 8.3
> > filepath with forward slashes seemed like a bug in our code, so I changed it
> > to an 8.3 filepath with backslashes. I tested the change with master, 5.0,
> > and old versions of PulseAudio, and then committed it to our code.
> 
> PulseAudio should create the necessary directories if they don't exist. The
> slash issue indeed sounds like a probable cause for the directory creation
> failure.
> 
> > Anyway, I need to do some actual testing. (My weekend is coming up, so I
> > have time available.) If said commit fixed the issue with cookie creation on
> > versions 3.0 through 5.0, then I could update x2goclient code to upload the
> > correct cookie depending upon which version of PulseAudio is installed.
> > However, it seems like less work for me to just specify an absolute cookie
> > path, or to specify %XDG_CONFIG_HOME%.
> 
> Setting XDG_CONFIG_HOME is probably not a good idea. If I understood
> correctly, you'd set USERPROFILE to "C:\Users\mike.DEPAULO\.x2go\pulse" and
> XDG_CONFIG_HOME to "C:\Users\mike.DEPAULO\.x2go". That probably works, but
> doesn't make sense conceptually. It would be similar to setting
> XDG_CONFIG_HOME on Linux to /home, and assuming that the user name is
> "pulse".
I see what you mean, I didn't think of that. I'll avoid doing this if at all possible.

So I tried passing an absolute 8.3 filepath (with backslashes) to auth-cookie. The result was not pretty:
http://pastebin.com/aYdxQ2d1
C:\Users\mike.DEPAULO\.x2go\pulse\.esd_auth was created successfully and it is 16 bytes.
However,
C:\Users\mike.DEPAULO\.x2go\pulse\.config\pulse\C was created instead of the absolute path I specified. "C" is the beginning of the absolute path. Furthermore, this cookie is only 0 bytes.
I think patch 9/9 is relevant to this behavior.

So what I'd prefer to do is fix PulseAudio's logic for determining/using absolute paths on Windows, and then have x2goclient specify an absolute path to C:\Users\mike.DEPAULO\.x2go\pulse\.pulse-cookie .

> So what I'd prefer to do is fix PulseAudio's logic for determining/using
> absolute paths on Windows, and then have x2goclient specify an absolute path
> to C:\Users\mike.DEPAULO\.x2go\pulse\.pulse-cookie .

That sounds like a good plan. I'm not sure PulseAudio is broken, though. From the log:

D: [(null)] pulsecore/authkey.c: Got 0 bytes from cookie file 'C:\Users\MIKE~1.DEP\X2GO~1\pulse\.config\pulse\C:UsersMIKE~1.DEPX2GO~1pulse.pulse-cookie', expected 256

It appears that PulseAudio stripped all backslashes. That's probably done by the module argument parsing code, which treats backslashes as escape characters. Try duplicating all backslashes in the module arguments.

(In reply to comment #26)
> > So what I'd prefer to do is fix PulseAudio's logic for determining/using
> > absolute paths on Windows, and then have x2goclient specify an absolute path
> > to C:\Users\mike.DEPAULO\.x2go\pulse\.pulse-cookie .
> 
> That sounds like a good plan. I'm not sure PulseAudio is broken, though.
> From the log:
> 
> D: [(null)] pulsecore/authkey.c: Got 0 bytes from cookie file
> 'C:\Users\MIKE~1.DEP\X2GO~1\pulse\.config\pulse\C:UsersMIKE~1.DEPX2GO~1pulse.
> pulse-cookie', expected 256
> 
> It appears that PulseAudio stripped all backslashes. That's probably done by
> the module argument parsing code, which treats backslashes as escape
> characters. Try duplicating all backslashes in the module arguments.

Thanks Tanu. You were correct. Double backslashes made absolute paths work for all 3 versions of PulseAudio I tested:
5.0
5.0-121-g38c5d
5.0-121-g38c5d-dirty (the 9 patches applied)

The argument I tested was:
auth-cookie=C:\\Users\\MIKE~1.DEP\\X2GO~1\\pulse\\.pulse-cookie
And I tested launching PulseAudio from the command-line, rather than from x2goclient.exe, but I consider that a sufficient test for X2Go Client's needs.

This is now fixed in master.

I can confirm this fix is working perfectly in libpulse 5.99.2-1 under Arch Linux.  Thank you Tanu!