Thank you both Lennart and Colin for your continued assistance.
I know /tmp IS being shared, that's why I can see two different
/tmp/pulse-XXXX folders being created when I try to use paplay from
within the 32-bit chroot. The relevant lines I run are:-
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 /home /opt/arch32/home
It's the weekend, and I won't be having access to that machine, so
please forgive any delay in replies, I do appreciate your assistance.
Colin Guthrie wrote:
> 'Twas brillig, and Ng Oon-Ee at 24/04/09 10:42 did gyre and gimble:
>> I'm part-way to a solution, but am not sure whether I'm doing things
>> right, please comment.
>>
>> Currently, I notice the variables PULSE_SERVER and the like are not
>> set on my Arch Linux install. Setting them did not make a difference,
>> initially, until I did further things.
>>
>> Basically, I changed pulseaudio to a system-wide instance (starting
>> as root with --system), copied the /var/run/pulse/.pulse-cookie to
>> /etc/pulse-cookie in the 32-bit chroot, did the appropriate chown to
>> pulse:pulse-access and chmod 640 to the cookie, and was able to play
>> sound using paplay -s localhost. It also works with
>> PULSE_SERVER=localhost.
>>
>> As I understand it, what I'm doing is using pulseaudio over a network
>> (though the chroot is actually on the same machine). All I'd have to
>> do now is set the PULSE_SERVER environment variable to get sound
>> working.
>>
>> Is this the right way to do it? Seems overly complicated for a
>> single-machine setup to me. Please advise.
>
> I'd very much advise *against* using a system wide pulseaudio. It's
> only really appropriate in certain special circumstances and this
> isn't one of them :)
>
> You should not need to set your PULSE_SERVER env var as it should be
> worked out automatically.
>
> I'd double check Lennart's reply as his comment about ensureing /tmp
> is shared in and out of the chroot is probably the point at which your
> original setup is failing.
>
> Col
>
>
>
>
