[pulseaudio-discuss] Pulseaudio server for playing 32-bit chroot sounds on 64-bit host machine

[Ng Oon-Ee]

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.