pulsesrc/pulsesink clocking issues

[Alexey Chernov]

Hello,
I experience some issues when trying to process sound from pulsesrc
and pulsesink elements. The pipeline is quite simple:

pulsesrc device=insert.monitor ! equalizer-nbands ! pulsesink device=output

"insert" device in Pulseaudio is module-null-sink device and "output"
device is module-alsa-sink device. In PA list I was suggested that
this problem could be clocking and synchronizing issue between system
and ALSA clocks. It seems to be right because I got the message

baseaudiosink gstbaseaudiosink.c:1035:gst_base_audio_sink_skew_slaving:<pulsesink0>
correct clock skew 20191929 > 20000000

on every click in sound stream (very much of such messages).

I think it can be solved by setting ALSA clock as master for the whole
pipeline. Is it possible? Is there any way at all to solve such a
problem?

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Wed, 2010-07-07 at 16:18 +0400, 4ernov wrote:

> Hello,
> I experience some issues when trying to process sound from pulsesrc
> and pulsesink elements. The pipeline is quite simple:
>
> pulsesrc device=insert.monitor ! equalizer-nbands ! pulsesink device=output
>
> "insert" device in Pulseaudio is module-null-sink device and "output"
> device is module-alsa-sink device. In PA list I was suggested that
> this problem could be clocking and synchronizing issue between system
> and ALSA clocks. It seems to be right because I got the message
>
> baseaudiosink gstbaseaudiosink.c:1035:gst_base_audio_sink_skew_slaving:<pulsesink0>
> correct clock skew 20191929 > 20000000
>
> on every click in sound stream (very much of such messages).
>
> I think it can be solved by setting ALSA clock as master for the whole
> pipeline. Is it possible? Is there any way at all to solve such a
> problem?

Not possible. If there are two devices with different clocks, one of
them needs to compensate for the drift. Currently this is done by
dropping samples or inserting silence when the drift is bigger than
20ms.

Another less audible way would be to resample the audio. Unfortunately
the stability of the resampler is not so good in the gstreamer elements
so it sounds quite bad (you can try with the slave-method property on
pulsesink).

Wim


>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Alexey Chernov]

Thanks, Wim, although not good news... And will queue or some other buffer
elements help this? Any normal delays won't hurt too much.

В сообщении от Среда 07 июля 2010 16:56:34 вы написали:

> On Wed, 2010-07-07 at 16:18 +0400, 4ernov wrote:
> > Hello,
> > I experience some issues when trying to process sound from pulsesrc
> > and pulsesink elements. The pipeline is quite simple:
> >
> > pulsesrc device=insert.monitor ! equalizer-nbands ! pulsesink
> > device=output
> >
> > "insert" device in Pulseaudio is module-null-sink device and "output"
> > device is module-alsa-sink device. In PA list I was suggested that
> > this problem could be clocking and synchronizing issue between system
> > and ALSA clocks. It seems to be right because I got the message
> >
> > baseaudiosink
> > gstbaseaudiosink.c:1035:gst_base_audio_sink_skew_slaving:<pulsesink0>
> > correct clock skew 20191929 > 20000000
> >
> > on every click in sound stream (very much of such messages).
> >
> > I think it can be solved by setting ALSA clock as master for the whole
> > pipeline. Is it possible? Is there any way at all to solve such a
> > problem?
>
> Not possible. If there are two devices with different clocks, one of
> them needs to compensate for the drift. Currently this is done by
> dropping samples or inserting silence when the drift is bigger than
> 20ms.
>
> Another less audible way would be to resample the audio. Unfortunately
> the stability of the resampler is not so good in the gstreamer elements
> so it sounds quite bad (you can try with the slave-method property on
> pulsesink).
>
> Wim
>
> > -------------------------------------------------------------------------
> > ----- This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel