Have you set default-server in client.conf or the PULSE_SERVER environment variable to point to the remote server? If you have, then PulseAudio thinks that you want to use the remote server, not the local machine. If you want to use both, you should not set default-server in client conf or the PULSE_SERVER environment variable. Instead, you should load module-zeroconf-discover on the local machine and module-zeroconf-publish and module-native-protocol-tcp on the remote machine. You can do the configuration with paprefs.

Thanks for your reply, I did have the env set, tried both places you mention, and had unset it to get things back to normal.

Have loaded the modules and copied the cookie without success... by which I mean that the modules appear in the lists but the remote sink or monitor do not appear locally.  It was my understanding that this would happen and the remote input could be sent to local outs.

The remote pc has an XM radio on the RCA in's of a M-Audio 2496, the signal is visible in the card software on the remote HW input side, but it doesn't seem to get anywhere useful.

Are my presumptions correct for pulseaudio, ie should the remote card appear in the local config?  Or perhaps the card is not doing something it is supposed to?





again, any help appreciated,


rikm

(In reply to comment #2)
> Thanks for your reply, I did have the env set, tried both places you
> mention, and had unset it to get things back to normal.
> 
> Have loaded the modules and copied the cookie without success... by which I
> mean that the modules appear in the lists but the remote sink or monitor do
> not appear locally.

About terminology: the thing that you want to appear locally is a "source", since it's the sound card input device that you're interested, not "sink" or "monitor".

> It was my understanding that this would happen and the
> remote input could be sent to local outs.

Sending audio from a source to a sink requires loading module-loopback, and connecting its playback and record streams to the right sink and source.

> The remote pc has an XM radio on the RCA in's of a M-Audio 2496, the signal
> is visible in the card software on the remote HW input side, but it doesn't
> seem to get anywhere useful.
> 
> Are my presumptions correct for pulseaudio, ie should the remote card appear
> in the local config?  Or perhaps the card is not doing something it is
> supposed to?

It's not clear to me if the source for the remote sound card is available locally or not. Use "pactl list sources" on the local machine to check. If it's not available, then something is not working as it should (assuming that these two machines are on the same LAN).

+
> pactl list sources

Thanks again for your continued attention, I signed up to the pa
listserv in hopes of gleaning something useful, but am reluctant to
intrude into what seems exclusively to be developers talking to each
other. Please let me know if I should move the discussion there, or
somewhere else... and thanks again for your help.


The source appears on the remote box, changes from State: SUSPENDED to
State: RUNNING when the XM receiver is switched on. 

It does not appear on the local box.  Manually loaded
'module-loopback' on both to see if either noticed, no changes
visible.  The two PC's are on the same segment.


Is that the same module that paprefs would load if the 'loop back
audio' button is pressed on the RTP tab? 

The RTP modules do not seem to load on the remote box [using ssh with
-X], does the 'module-loopback' loaded with pactl need configuring on
the CLI input?

So should the RTP stuff be running on both boxes, and do additional
ports [beyond 4713], need to be opened on the firewalls for that to
work?  Are any other firewall ports required for anything else?


thanks,


rikm

(In reply to comment #4)
> +
> > pactl list sources
> 
> Thanks again for your continued attention, I signed up to the pa
> listserv in hopes of gleaning something useful, but am reluctant to
> intrude into what seems exclusively to be developers talking to each
> other. Please let me know if I should move the discussion there, or
> somewhere else... and thanks again for your help.

The mailing list is meant for both users and developers, so it's fine to ask help there.

> The source appears on the remote box, changes from State: SUSPENDED to
> State: RUNNING when the XM receiver is switched on. 
> 
> It does not appear on the local box.  Manually loaded
> 'module-loopback' on both to see if either noticed, no changes
> visible.  The two PC's are on the same segment.

module-loopback won't be of any help before you have the remote source visible locally.

> Is that the same module that paprefs would load if the 'loop back
> audio' button is pressed on the RTP tab? 

No, I think the RTP loopback uses some other mechanism.

> The RTP modules do not seem to load on the remote box [using ssh with
> -X], does the 'module-loopback' loaded with pactl need configuring on
> the CLI input?
> 
> So should the RTP stuff be running on both boxes, and do additional
> ports [beyond 4713], need to be opened on the firewalls for that to
> work?  Are any other firewall ports required for anything else?

RTP streaming is a different thing than the normal network setup. You don't need the RTP modules for anything.

module-zeroconf-publish and module-zeroconf-discover use Avahi for communicating with each other, so the Avahi port (UDP 5353) needs to be open in the firewall.

>
>
> RTP streaming is a different thing than the normal network setup. You don't
> need the RTP modules for anything.

ok then, good to know


>
> module-zeroconf-publish and module-zeroconf-discover use Avahi for
> communicating with each other, so the Avahi port (UDP 5353) needs to be open in
> the firewall.

...had figured that, already set on both boxes... does something need
to be done with avahi itself?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/383.