Re: [pulseaudio-discuss] Working on a new network transport for PulseAudio
On Fri, 10 May 2019 21:15:48 +0300 Tanu Kaskinen wrote: > On Mon, 2019-05-06 at 21:35 +0400, Victor Gaydov wrote: > > Hi, > > > > I'm working on Roc, a new project implementing real-time streaming > > over network[1]. > > > > Currently it can stream PCM using RTP + FECFRAME (Reed-Solomon and > > LDPC-Staircase are supported, using OpenFEC library). There are > > plans to add support for more encodings (including Opus) and > > protocols (including SAP/SDP). > > > > Among other things, we've implemented a couple of PulseAudio modules > > that use Roc as a network transport. I've written an overview post > > about the project and these modules[2]. > > > > Both Roc and PA modules are in early stage of development. PA > > modules still miss some essential features, e.g. there is no > > latency reporting and service discovery. > > > > I'd like to discuss the opportunity of submitting those modules to > > the PA upstream in future. Some thoughts? > > > > [1] https://github.com/roc-project/roc > > [2] https://gavv.github.io/articles/new-network-transport/ > > > > -- Victor > > Miscellaneous thoughts in random order: > > At least I'm in favor of accepting the new modules in PulseAudio, if > they provide less glitches than the tunnel modules or the existing RTP > modules. And I'd love to have the adaptive resampling logic maintained > in an external library by someone who knows how it works (I don't > understand and I don't look forward to trying to learn how the > resampling code in the existing RTP modules works). Great! > I should probably mention that if you submit patches, I can't promise > a timely review - there's too much work that I'm already committed to. OK. > Arun has in the past talked about some plans for reworking the RTP > stuff to use GStreamer - I hope that won't be an impediment for > accepting these modules. Interesting. This should be discussed, I think, because Roc features overlap with the network part of GStreamer. > Are there any plans to support multicast? I don't know how important > that is to people, it's just that I think the existing RTP modules use > multicast by default (which tends to break wireless networks...) Multicast is in our roadmap, but I'd like to work on it a bit later, after implementing some more basic stuff like receiver feedback, session negotiation, and compression. > Can one receiver connect to multiple senders? If there are two client > machines that want to use speakers connected to a single receiver > machine, does module-roc-sink-input have to be loaded twice (and with > different ports)? Single receiver handles multiple senders connected to it (and mixes their streams). > Any plans for dynamic latency based on stream requests? If the goal is > to support low latency, it's probably desirable to have a bit larger > latency for music playback, and reduce the latency on the fly when a > low-latency application starts. There are plans to implement automatic latency adjustment (depending on the network conditions) on the receiver side. Allowing the user to adjust the latency manually on the sender side sounds reasonable but we need to think what protocols are suited for that. Probably RTSP, which is in our roadmap. > How much of the parameters could theoretically be changed on the fly > (I say theoretically, because you probably haven't implemented any > such controls yet)? Imagine a GUI for configuring this system - trying > different resampler profiles or latency settings on the fly could be > useful. Changing the IP address or port probably doesn't need to be > doable mid-stream. Currently it's not possible to change anything on fly, except binding new ports. There are plans to implement automatic adjustment of latency, FEC block size, packet size, and bitrate. This means that in future all these parameters will be configurable on fly at least internally. And so it would be possible to make them configurable via API too. > People have requested in the past that the tunnel sink would change > the stream sample rate and format on the fly based on the > application's stream, similar to how the hardware sink supports > automatic sample rate switching. Would this be doable? It doesn't > need to (and indeed shouldn't) be done mid-stream, but if nothing is > currently using the Roc sink and a new stream appears, it would be > good to configure the network stream parameters based on the > application stream. I think it would be possible after we'll add some sort of session negotiation (RTSP or SIP). I'm planning to start working on it soon. > The blog post has this sentence: "Roc performs the clock rate > adjustment on the receiver, while PulseAudio does it on the sender" - > that's not true. Doing the adjustment on the sender would require some > kind of feedback system from the receiver to the sender, and that > doesn't exist. PulseAudio does the adjustment on the receiver. My bad. Fixed. > What happens if the connection dies temporarily
[pulseaudio-discuss] [PATCH] stream-restore: Don't restore if the active_port is PA_AVAILABLE_NO
We met two problems recently, one happened on a Lenovo machine with
dual analogue codecs, the other happened on a Dell machine with
a digital mic directly connected to PCH. The two problems are
basically same, there is an internal mic and an external mic, the
internal mic always shows up in the gnome-control-center, the external
mic only shows up when it is plugged. After the external mic is
plugged and users select it from gnome-control-center, the
gnome-control-center will read all saved streams through extension_cb,
and bind the source of external mic to all streams, after that the
apps only record sound via the source of external mic, after the
external mic is unplugged, the internal mic will automatically be
selected since it is the only left input device in the
gnome-control-center, since users don't select it, all streams are
still bond the source of external mic. When users record sound via
apps, they can't record any sound even the default_source is the
source of internal mic and the internal mic is selected in the UI.
It is very common that a machine has internal mic and external mic,
but this problem didn't expose before, that is because both internal
mic and external mic belong to one source, but for those two
machines, the internal mic belongs to one source, while the external
mic belongs to another source (they are in differnt codecs or one is
in the codec and the other is from PCH),
To fix it with a mininal change, we just check if the active_port is
PA_AVAILABLE_NO or not when building a new stream, if it is, don't
restore the device to the new built stream, let pa_source_output_new()
decide the source device for this stream.
And we also do the same change to sink_input.
This change only affects the new built streams, it will not change
the database, so the users' preference is still saved in the database,
after the active_port is not PA_AVAILABLE_NO, the new streams will
still restore to the preferred device.
Signed-off-by: Hui Wang
---
src/modules/module-stream-restore.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/modules/module-stream-restore.c
b/src/modules/module-stream-restore.c
index 6c7b4c75b..cbef4782d 100644
--- a/src/modules/module-stream-restore.c
+++ b/src/modules/module-stream-restore.c
@@ -1459,8 +1459,10 @@ static pa_hook_result_t
sink_input_new_hook_callback(pa_core *c, pa_sink_input_n
same time, in which case we want to make sure we don't
interfere with that */
if (s && PA_SINK_IS_LINKED(s->state))
-if (pa_sink_input_new_data_set_sink(new_data, s, true, false))
-pa_log_info("Restoring device for stream %s.", name);
+if (!s->active_port || s->active_port->available !=
PA_AVAILABLE_NO) {
+if (pa_sink_input_new_data_set_sink(new_data, s, true, false))
+pa_log_info("Restoring device for stream %s.", name);
+ }
entry_free(e);
}
@@ -1562,8 +1564,10 @@ static pa_hook_result_t
source_output_new_hook_callback(pa_core *c, pa_source_ou
same time, in which case we want to make sure we don't
interfere with that */
if (s && PA_SOURCE_IS_LINKED(s->state)) {
-pa_log_info("Restoring device for stream %s.", name);
-pa_source_output_new_data_set_source(new_data, s, true, false);
+if (!s->active_port || s->active_port->available !=
PA_AVAILABLE_NO) {
+pa_log_info("Restoring device for stream %s.", name);
+pa_source_output_new_data_set_source(new_data, s, true, false);
+ }
}
entry_free(e);
--
2.17.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
