[pulseaudio-discuss] paprefs port setting
pulseaudio-discuss at nicohood.de
Mon Oct 31 17:04:59 UTC 2016
On 10/31/2016 04:49 PM, Tanu Kaskinen wrote:
> On Mon, 2016-10-31 at 15:02 +0100, NicoHood wrote:
>> I am currently actively using pulseaudio for streaming audio over
>> network. I found RTP the most promesing method for me. However there is
>> a problem I ran into which I'd like to solve. I've also prepared a
>> possible solution.
>> My goal is to stream music via RTP and paprefs. Quick setup on the
>> sender side and quick setup on the receiver side if also pulse+paprefs
>> is used. Now my receiver is a raspberry pi which uses kodi + alsa as
>> pulse is too slow on it for some reason (general lag, even for local
>> playback). But kodi also can playback an RTP stream directly:
>> Create a file named pulse.strm with the content: rtp://@184.108.40.206:46400
>> Now the problem is that the port always changes, as paprefs does not set
>> any specific port. The module it uses is module-rtp-send:
>> I am wondering if you can set the default port for this module globally
>> via config file. If not the only way to fix this issue is to provide a
>> way for paprefs to use a fixed port. Due to the fact that the source
>> port is always random and the pulse sink listens to all ports it would
>> not matter much if the sender would always send with a fixed port. Using
>> a fixed port is simple to patch and works for me:
>> Just change line 537 of paprefs.cc to the following:
>> Glib::ustring(loopbackEnabled ? "source=rtp.monitor loop=1 port=46400" :
>> "source=rtp.monitor loop=0 port=46400"));
>> Now paprefs creates a sender with the same port. You may want to use a
>> different port, but basically that'd solve the problem. And existing
>> setups would still work.
>> Is there a way to get this fix applied? Or are there any other
>> suggestions? FYI: the same also applies to vlc playback, not only kodi.
> The first question comes to mind is why do we randomize the port in the
> first place? Is it for security reasons or what? Given that the port is
> selected from a pool of only 256 ports, the reason is probably not
> really security-related. Maybe it's to make conflicts unlikely if two
> computers in a network load module-rtp-send?
> Ideally paprefs would let the user choose between a random port or a
> manually selected one. Would you be willing to implement this? If not,
> changing paprefs to just pick one port as you suggested would probably
> still be an improvement over the status quo. The UI should indicate
> what the port is, though.
> paprefs should also detect the situation where the gconf key is still
> set to the old value (i.e. no port in the module argument list) and
> change it to the new value automatically.
I dont know why you randomize it, but even if you have two senders you
will have the problem that the receiver will play two streams at the
same time. I am not sure if that is too clever anyways.
An extra field for a fixed port would be great. However I am afraid that
I have no knowledge in this field, I've just quick patched the source to
find the cause of the bug.
But you are right that a fixed port could solve the issue for now and
dont cause too much trouble. I've also tested what happens if two
senders use the same port: The first opened stream will be used and if
both are already opened one of the two will be used (with kodi as
receiver). Using pulse with paprefs as receiver will cause trouble if
you have two streams on the same port. If they are on a different port
it sometimes makes the receiver stop working, then you need to reenable
one sender, then it works again (playing both streams at the same time).
This buggy behavior can be caused by my raspi as its slower. So for
people using 2 senders this would possibly be a regression, however I am
not sure how many of us do this.
The source does not seem to be too complex but is there someone I could
ask for some help to place me a proper textfield +checkbox in that
source correctly? I am mainly active on irc or on tox. I will try to
have a look at this the next days. If i can get some help (have to
analyze this first) and someone who is willing to merge it, I would try.
More information about the pulseaudio-discuss