On 13.02.22 21:02, corbeille wrote:
I will try to use the loopback module since it performs adaptive
resampling between source and sink.
If I understand what you write, I should use something like this :
$ pacmd load-module module-null-sink sink_name=MySink
$ pacmd load-module module-null-sink sink_name=MySink2
$ pacmd load-module module-loopback source=alsa_input.usb-0d8c_C-
Media_USB_Headphone_Set-00.mono-fallback sink=MySink2
And then start my two gstreamer pipelines :
$ gst-launch-1.0 pulsesrc device=MySink2.monitor ! audioconvert !
audioresample ! pulsesink device=MySink
$ gst-launch-1.0 pulsesrc device=MySink.monitor ! audio/x-
raw,channels=2 ! audioconvert ! audioresample ! opusenc bitrate=256000
! oggmux ! shout2send ip=... port=... mount=... password=...
Is it correct ?
Yes, that's correct.
At this moment, I don't try to mesure latency between audio input and
output.
++
Jack
Le dimanche 13 février 2022 à 20:17 +0100, Georg Chini a écrit :
On 13.02.22 17:09, corbeille wrote:
Hey Georg,
I have updated my to raspios since last time : Debian GNU/Linux 11
(bullseye).
It comes with :
- pulseaudio 14.2
- GStreamer 1.18.4
Is it also too old ?
I was hoping to avoid installing pulseaudio from source.
If so, I will give it a try...
++
Jack
Well, 14.2 is at least not completely out of date. Nevertheless I
would try
current git. What I wonder about is that the problem only occurs with
a
second null sink. Are you sure about that? The two null sinks should
not
interact at all. Maybe with the second null sink the problem occurs
only
later?
I can understand that there is an issue, because the system time and
sound
card time are normally different. So if the source for example (from
a
system
time perspective) delivers samples at 48003 Hz while the samples are
played
with 48000 Hz you will have three samples left per second which pile
up
pretty fast. module-loopback has mechanisms to deal with the rate
difference
between source and sink. Maybe you can try to use a loopback from the
alsa
source to a null-sink and then use the monitor of that null sink in
your
first
gst-launch command instead of using the alsa source directly.
Do you see increasing latency before the sound gets choppy?
Le dimanche 13 février 2022 à 17:05 +0100, Georg Chini a écrit :
On 13.02.22 16:57, corbeille wrote:
Hello,
I did some additional tests.
And it seems the problem occurs when I have a second null sink.
With
only one null sink, I don't have any problem. Weird.
So here is an example of the configuration that causes the
problem
:
1st shell:
$ pacmd load-module module-null-sink sink_name=MySink
$ pacmd load-module module-null-sink sink_name=MySink2
2nd shell:
$ gst-launch-1.0 pulsesrc device="alsa_input.usb-0d8c_C-
Media_USB_Headphone_Set-00.analog-mono" ! audioconvert !
audioresample
! pulsesink device=MySink
3rd shell:
$ gst-launch-1.0 pulsesrc device=MySink.monitor ! audio/x-
raw,channels=2 ! audioconvert ! audioresample ! opusenc !
oggmux !
shout2send ip=... port=... mount=... password=...
After 20 minutes, the sound becomes choppy and stop 4/5 minutes
after.
You can notice that I don't use the second null sink.
Is it a normal behavior ? If so, how can I do to achieve this
configuration on my RPi (by using multi null sink) :
gst_input1 => MySink => gst output1
gst_input2 => MySink2 => gst output2
without any trouble ?
Thanks.
++
Jack
Le vendredi 11 février 2022 à 21:33 +0100, corbeille a écrit :
Hello,
I am using pulseaudio (version 12.2) to "join" two audio
streams
created
with gstreamer (1.14.4) on a raspberry pi (Raspbian GNU/Linux
10
(buster)).
Here the real things :
In a first shell, i start with :
$ pacmd load-module module-null-sink sink_name=MySink
Then I use gstreamer to get the sound from my audio input (in
an
other
shell) :
$ gst-launch-1.0 pulsesrc
device="alsa_input.usb-0d8c_C-Media_USB_Headphone_Set-
00.analog-
mono"
!
audioconvert ! audioresample ! pulsesink device=MySink
and I send this sound on an icecast server (in an other
shell) :
$ gst-launch-1.0 pulsesrc device=MySink.monitor !
"audio/x-raw,channels=2" ! audioconvert ! audioresample !
opusenc
!
oggmux ! shout2send ip=... port=... mount=... password=...
Everything is fine, but after 10 minutes, I get in the 3rd
shell
($
gst-launch-1.0 pulsesrc device=MySink.monitor ! ...) a
sequence
of
messages like :
WARNING: from element
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(849): gst_audio_base_src_create ():
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 10080 samples. This is most likely because downstream
can't
keep
up and is consuming samples too slowly.
WARNING: from element
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(849): gst_audio_base_src_create ():
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 34560 samples. This is most likely because downstream
can't
keep
up and is consuming samples too slowly.
WARNING: from element
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(849): gst_audio_base_src_create ():
/GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 48000 samples. This is most likely because downstream
can't
keep
up and is consuming samples too slowly.
...
The sound become glitchy and stop after 2 or 3 minutes.
According to the message, the stream after "pulsesrc
device=MySink.monitor" is too slow. But I don't understand
why.
Do you know where is the problem in this setup and how to
solve
it ?
Thanks !
++
Jack
Hello,
have you tried with a more recent version of pulseaudio? 12.2 is
pretty
old. You should use 15.0 or current git.
Regards
Georg
