[pulseaudio-discuss] PA 10 : paplay can't connect !

sean darcy seandarcy2 at gmail.com
Tue Feb 7 23:02:47 UTC 2017

On 02/06/2017 06:51 AM, Tanu Kaskinen wrote:
> On Wed, 2017-02-01 at 16:39 -0500, sean darcy wrote:
>> On 01/28/2017 07:22 AM, Tanu Kaskinen wrote:
>>> I suspect
>>> {fd19a5b3f9ab48aeae18d687a1e5c0cc}unix:/run/user/1001/pulse/native
>>> comes from the X server. On your Fedora laptop, module-x11-publish puts
>>> the local pulseaudio socket addresses to X properties, and when you use
>>> ssh with X forwarding, paplay takes the socket address from the X
>>> server running on your laptop.
>>> The intended purpose of this is that if you load module-native-
>>> protocol-tcp  (notice the -tcp suffix) on the laptop, applications that
>>> you use on the remote machine over ssh automagically connect to the
>>> local pulseaudio server on your laptop. In this case, however, if my
>>> guess is correct, paplay picks up a unix socket address from X, which
>>> is not useful at all.
>>> The {fd19a5b3f9ab48aeae18d687a1e5c0cc} part is supposed to be a filter
>>> that tells paplay to use the address only if the machine that paplay
>>> runs on has machine-id fd19a5b3f9ab48aeae18d687a1e5c0cc. What's the
>>> machine-id of the Fedora laptop, and what's the machine-id of the
>>> headless server? The machine-id is stored in /etc/machine-id. If
>>> they're the same on the two machines for some reason, then that's the
>>> problem.
>>> "xprop -root | grep ^PULSE_" will show the stuff that pulseaudio has
>>> stored in the X server.
>>  From the headless server:
>> [video at sixcore ~]$ cat /etc/machine-id
>> ef65454e1a334e1e93f8ff6b0000000f
>> [video at sixcore ~]$ xprop -root | grep ^PULSE_
>> "8c9ea5d609d838341a2b6335601ae5e8c107dae72a15421f0e9074893277fb7c2d311a68a7f5f61dfa532885bdeb0b14d7ce00a331a107fe88cebfc47bb7ead716b4fea6c5a6aa95303f6adf20827db2b56e2deb895e3152c198afadfa19c3bc514a0ca9ff4776f34fca4f9a67dc0f24a591606faadf66b90b92e832ed05b51a79095b8ee2129a7de14af953ac118733ce094234dc7df23d850672c4e5af5ebfc541089cc1f0a05754b9b77d1bee0325845688b3fd4e75d8aaadddfb10319f2156c14dbfd7ea62222ee9b73d2cccb42b71968236744caf5c09a04b4a501c6c4cf28190a115ed3b1fb90b3ef9b51d461a09c5c011350987dc00a021c16708b638"
>> "{fd19a5b3f9ab48aeae18d687a1e5c0cc}unix:/run/user/1001/pulse/native"
> There seems to be some kind of bug. paplay on the server should not try
> to use this address, because the machine-id in the address doesn't
> match the server's machine-id.
>> PULSE_ID(STRING) = "1001 at fd19a5b3f9ab48aeae18d687a1e5c0cc/1718"
>> The machine-id of the fedora laptop is fd19a5b3f9ab48aeae18d687a1e5c0cc
>> and I'm user 1001 on that machine.
>> If I switch to a console on the Fedora laptop ( CTL-ALT-F4) , and ssh
>> into the server, everything works. The music plays on the server.
>> So if X were running on the headless server, the music would play from
>> my laptop ?
> I think running X on the server would make no difference, because I
> think the X forwarding in ssh would still tell applications to use X on
> the laptop.
>> Now that I know I can use the console, that's a decent workaround. Also
>> when I remove module-native-protocol-tcp.so, that also works. Does that
>> module have any function other than remote playback ?
> The purpose of the module is to allow remote connections. It's not
> limited to playback. If you don't need remote connections, then you can
> safely remove the module from the configuration (but then why was it
> there to begin with?).
> I'm confused about what's happening here. I suppose you had module-
> native-protocol-tcp loaded on the laptop? In that case the TCP address
> should have been set in the PULSE_SERVER property, not the unix socket.
>  If you don't load module-native-protocol-tcp, is the PULSE_SERVER
> property not set?
I moved the tcp module , so it's not loaded on the laptop:

[sean at lenovo ~]$ xprop -root | grep PULSE
[sean at lenovo ~]$

I then loaded the tcp module:

[sean at lenovo ~]$ xprop -root | grep PULSE
tcp:lenovo.riverside:4713 tcp6:lenovo.riverside:4713"
PULSE_ID(STRING) = "1001 at fd19a5b3f9ab48aeae18d687a1e5c0cc/1641"


More information about the pulseaudio-discuss mailing list