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
