Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is manipulated by the code in src/pulsecore/authkey.c. Currently it does this to read the key:
1) Open the file
2) Acquire a write-lock for the file.
3) Read the file.
4) If the file is not a good cookie, generate a new cookie and write it to the file.
5) Close the file.
If more than one thread is opening the cookie at once, then there is contention at step (2) which is rarely necessary. Instead, step (2) should acquire only a read-lock, and then step (4) should promote that to a write-lock before writing the file.
This is particularly bad in the case where the .pulse-cookie file is on NFS. In that case, the lock contention forces a thirty-second backoff from whichever thread gets there second.
I am happy to work with y'all in engineering a patch for this. It requires obviously a change to src/pulsecore/authkey.c, and a corresponding one in src/pulsecore/core-util.c where the actual lock syscall occurs.
The following script (if ~ is in NFS) will demonstrate the problem. The two pactl processes both try to acquire the lock on the file simultaneously, and whichever one loses will take thirty seconds before it wins, because of the needless contention (and the unfortunate facts of how lockd in NFS works).
!/bin/bash
NUM_PROCS=2
procs=()
for i in $(seq 1 $NUM_PROCS); do
pactl list > /dev/null &
procs[$i]=$!
done
for i in $(seq 1 $NUM_PROCS); do
wait ${procs[$i]}
done