[pulseaudio-discuss] Glitches on null sink?

[Tanu Kaskinen]

On Fri, 2011-05-20 at 21:28 +0200, marcin at saepia.net wrote:
> Hi,
> 
> I continue to develop my radio audio routing software so I continue to
> encounter strange bugs.
> 
> General idea that lies behind my project is to split some processing
> parts into separate processes. There are many reasons why this
> architecture has to be like this, it something fundamental and won't
> change.
> 
> For processing individual elements I use GStreamer (no external
> bindings, my code is in C).
> 
> There're many advanced dedicated input sources, such as
> RTP/VoIP/shoutcast. All of them load their own null sink module, and
> perform output on one. Other modules that broadcast the signal to the
> FM/net just leech from their ".monitor" PA sources. To this moment
> everything works flawlessly, even if I load huge amount of sources.
> 
> The problem is when I try to perform some audio processing or/and
> mixing. Currently I do that in the following way:
> 
> 1. Load another null sink module for mix output.
> 2. Run GStreamer's pipelines (each is also a separate process), e.g.:
>  a) pulsesrc device=source1.monitor ! processor1 ! processor2 !
> pulsesink device=mix
>  b) pulsesrc device=source2.monitor ! processor3 ! processor4 !
> pulsesink device=mix
> 
> It generally works ok, but from time to time, output (captured from
> mix.monitor) becomes full of glitches. Sounds like something lost
> synchronisation. And it's really hard to reproduce. Sometimes I run
> that kind of pipeline and it works for a long time and then it starts
> doing weird things, sometimes it starts it from the beginning.
> 
> When it starts producing glitches, pulsesrc element in the GStreamer
> pipeline throws an error that it cannot read samples fast enough. What
> is interesting, when it starts doing that, any other audio that I pass
> to this "mix" sink also sounds bad from the begin. Only reloading
> module helps.
> 
> 
> My theory is that I have to use module-combine to perform such mixing.
> Am I correct?

I don't think module-combine is relevant here. It should do mixing in
the exact same way as module-null-sink and all other sinks. I don't
guarantee that anyone will volunteer debugging this problem (it doesn't
sound easy), but could you upload somewhere a sample recording of the
glitchy audio?

> I wanted to avoid that as I am unable to dynamically add its slaves,
> but if it's the only way to perform such mix, I will do that, and
> reload it when my dedicated sources' list changes... It's not too
> pretty as it would produce short drops, but it's still acceptable.
> 
> I just want you to ask if I am seeking for the problem in the correct
> place, just before I spend a week on refactoring my code. Maybe
> pipeline like shown above (pulseaudio -> GStreamer -> pulseaudio) also
> is a wrong approach?

Generally pulseaudio -> app -> pulseaudio is a non-optimal approach,
because the source and the sink usually have different clocks, and
therefore they drift. There should be some adaptive resampling to
mitigate the drift. I have an impression that GStreamer provides this
kind of resampling, though. If you don't already have one, you could try
adding a queue element in the GStreamer pipelines (this may be
completely bogus advice, though, as I'm not a GStreamer expert).

-- 
Tanu