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.
