Colin Guthrie wrote:
'Twas brillig, and Ng Oon-Ee at 25/04/09 13:45 did gyre and gimble:
So, back to the matter at hand, any suggestions on what I might try
when I regain access to my PC? Colin mentioned that networked Pulse
should not be necessary, and that's my gut feeling as well, though I
HAVE got it working with that. Perhaps I need to edit client.conf
within the chroot to use the .pulse-cookie within the user's home
directory, similarly to how I need to edit it when using networked
Pulse? Shouldn't that be automatic, anyhow?
Well you shouldn't *need* to enable networking, but it may be a quick
and simple way to get it working (albeit with increased overhead).
You shouldn't need to edit client.conf as the built in mechanisms in
pulse should be sufficient to work out where to connect.
FWIW, the logic is something like this:
1. Check for client.conf and use it if specified.
2. Check for PULSE_SERVER env var and use it if specified
3. Check for PULSE_SERVER X11 property (xprop -root | grep PULSE) and
use it if specified.
4. Connect to the local server via the socket in the "runtime" directory.
5. Autospawn a local pulse server and connect to it.
The runtime directory is specified as a symlink inside ~/.pulse/ It
should look like "ac481238bcef82:runtime" where the random string of
characters is your "machine id". Make sure you don't have two
different machine ids listed in your ~/pulse folder pointing to
different runtime folders. If you do, then this is likely a problem.
Report back and we'll try and work that one out.
Col
Ah, what a hectic day. Starting off with an accidental system reformat
is never a good thing. Things are back in working order, though, and I
gained an additional x86_64 install to test on. I have not done anything
special except for setting up the 32-bit chroot and installing
pulseaudio and alsa-related stuff on both the host and the 32-bit
chroot. Client.conf has been left virgin, PULSE_SERVER env var is not
set, neither does xprop -root | grep PULSE return anything. When I start
up my machine, this is the output of `ls -la ~/.pulse`
total 60
drwx------ 2 ngoonee ngoonee 4096 2009-04-27 17:37 .
drwx------ 53 ngoonee ngoonee 4096 2009-04-27 17:39 ..
-rw------- 1 ngoonee ngoonee 12288 2009-04-27 17:37
97d309d0bcf94d1cd753ce7449f50f47:card-database.x86_64-unknown-linux-gnu.gdbm
-rw-r--r-- 1 ngoonee ngoonee 19 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:default-sink
-rw-r--r-- 1 ngoonee ngoonee 18 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:default-source
-rw------- 1 ngoonee ngoonee 13736 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:device-volumes.x86_64-unknown-linux-gnu.gdbm
lrwxrwxrwx 1 ngoonee ngoonee 23 2009-04-27 17:37
97d309d0bcf94d1cd753ce7449f50f47:runtime -> /tmp/pulse-PKdhtXMmr18n
-rw------- 1 ngoonee ngoonee 13147 2009-04-27 17:40
97d309d0bcf94d1cd753ce7449f50f47:stream-volumes.x86_64-unknown-linux-gnu.gdbm
Once I chroot into my 32-bit chroot, this is the output of `ls -la ~/.pulse`
total 96
drwx------ 2 ngoonee ngoonee 4096 2009-04-27 17:42 .
drwx------ 53 ngoonee ngoonee 4096 2009-04-27 17:39 ..
-rw------- 1 ngoonee ngoonee 12288 2009-04-27 17:42
0e0aa8e4defa50a16bb9d5c349f5dd35:card-database.i686-pc-linux-gnu.gdbm
-rw------- 1 ngoonee ngoonee 12288 2009-04-27 17:42
0e0aa8e4defa50a16bb9d5c349f5dd35:device-volumes.i686-pc-linux-gnu.gdbm
lrwxrwxrwx 1 ngoonee ngoonee 23 2009-04-27 17:42
0e0aa8e4defa50a16bb9d5c349f5dd35:runtime -> /tmp/pulse-2L9K88eMlGn7
-rw------- 1 ngoonee ngoonee 12288 2009-04-27 17:42
0e0aa8e4defa50a16bb9d5c349f5dd35:stream-volumes.i686-pc-linux-gnu.gdbm
-rw------- 1 ngoonee ngoonee 12288 2009-04-27 17:37
97d309d0bcf94d1cd753ce7449f50f47:card-database.x86_64-unknown-linux-gnu.gdbm
-rw-r--r-- 1 ngoonee ngoonee 19 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:default-sink
-rw-r--r-- 1 ngoonee ngoonee 18 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:default-source
-rw------- 1 ngoonee ngoonee 13736 2009-04-27 17:38
97d309d0bcf94d1cd753ce7449f50f47:device-volumes.x86_64-unknown-linux-gnu.gdbm
lrwxrwxrwx 1 ngoonee ngoonee 23 2009-04-27 17:37
97d309d0bcf94d1cd753ce7449f50f47:runtime -> /tmp/pulse-PKdhtXMmr18n
-rw------- 1 ngoonee ngoonee 13147 2009-04-27 17:40
97d309d0bcf94d1cd753ce7449f50f47:stream-volumes.x86_64-unknown-linux-gnu.gdbm
So, as can be seen, the 32-bit install ignores the 'runtime' within
~/.pulse, hence the reason my /tmp contains a few pulse-XXXX
directories. It is falling through to condition 5 in your steps.
Please advise whether I should attempt the tripping of steps 1-3, since
I believe that it would be better from the perspective of bug-fixing to
try and isolate the reason why step 4 does not work as it should.
Once again, I list my mounts for the 32-bit chroot.
mount --bind /proc /opt/arch32/proc
mount --bind /proc/bus/usb /opt/arch32/proc/bus/usb
mount --bind /dev /opt/arch32/dev
mount --bind /dev/pts /opt/arch32/dev/pts
mount --bind /dev/shm /opt/arch32/dev/shm
mount --bind /sys /opt/arch32/sys
mount --bind /tmp /opt/arch32/tmp
mount --bind /var/abs/local /opt/arch32/var/abs/local
mount --bind /home /opt/arch32/home
mount --bind /home/data /opt/arch32/home/data
Thanks for your help so far.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
