[pulseaudio-discuss] Virtual device in Pulseaudio

[4ernov]

Tanu, thank you very much for detailed answer. I've experimented on
the problems following your suggestions.

> On Wed, 2010-07-07 at 11:32 +0400, 4ernov wrote:
> > No, I actually didn't try the equalizer from git as the solution with
> > null sink worked ok. However I faced some troubles with it during
> > further development:
> > 1. Sometimes when I start GStreamer app with source in monitor of null
> > sink and sink in PA's alsa sink through equalizer plugin it plays as
> > if with the wrong samplerate is set i.e. sounds are pitched down and
> > are very distorted. I can avoid this only by killing and restarting my
> > equalizer application.
>
> This sounds strange. If you don't apply any equalization, just pipe the
> audio from input to output, does this happen? If it doesn't, the problem
> is probably in your equalizer. If it does happen even without the
> equalizer, what if you use a filesink instead of pulsesink as your
> target? Do you get any files with messed up pitch?

Yes, sound is distorted even without equalizer in pipeline (you are
right, I use equalizer-nbands Gst plugin with 10 bands). But if I send
the stream to filesink instead of pulsesink the result is ok in all
the tries I've done (about 10). What I do: at first send signal to
filesink with pipeline like pulsesrc ! wavenc ! filesink and then
playback file with filesrc ! decodebin ! audioconvert ! pulsesink. It
always plays ok.

>
> > 2. Several seconds after equalizer application started there're some
> > clicks and drops in output. I've read about glitch-free algorithm
> > which can lead to these problems but I've also read that they were
> > fixed.
> >
> > Tanu, can some of these problems be due to buffering issues you wrote?
> > Or perhaps there're some settings to fix them besides using equalizer
> > from git (that's the possible way for me but I still would like to
> > make it as GStreamer app if problems above can be solved somehow).
>
> The second problem sounds like it could be explained by the drift
> between two clocks.
>
> In case you're not familiar with the problem, it's this: the null sink
> uses the system clock and the alsa sink uses the sound card's clock.
> They are not perfectly in sync. Let's assume that the system clock is
> perfect, and if we ask for 48000 Hz sample rate, that's exactly what we
> get. The actual sample rate of the sound card might be 48100 Hz.
>
> Even though the alsa sink claims to have 48000 Hz sample rate, it
> actually asks for about 1.002 seconds of audio every second. The null
> sink still provides only one second of audio every second, so sooner or
> later there will inevitably be an underrun and drop-out (unless some
> adaptive resampling is used). Or many drop-outs. It could be that the
> pulsesink element always fulfills the requests from the alsa sink fully
> so that every buffer that is sent to the alsa sink has a tiny piece of
> silence at the end.
>
> I don't know how the pulsesink and pulsesource elements work, nor do I
> know how buffering in GStreamer works in general, so I don't know what
> actually happens if a pipeline has a clocked element at both ends. Btw,
> is your equalizer implemented as a GStreamer element (in the preceding
> text I assume that you do) so that you just create a pipeline like this:
> pulsesrc ! eq ! pulsesink?

Yes, that's right, my exact pipeline.

The interesting thing is that GStreamer prints the following messages
in console:

0:00:00.034730397  2822  0x9789bf0 WARN                     bin
gstbin.c:2312:gst_bin_do_latency_func:<equalize> failed to query
latency

- once at the very beginning (seems that when entering PLAYING state)

And

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

is printed every time when click or drop in stream appears. I think
it's the issue that you described. I think whether it can be fixed by
setting master clock of Gst pipeline if it's possible.

To be more exact, clicks are so often at the beginning then the
process somehow stabilizes and clicks become more rare but never
disappear at all. Also, maybe pitchiing and distorting issue has the
same cause if it can't synchronize clocks forever for example.

>
> It might be that GStreamer actually does support adaptive resampling if
> there are many clocks in a pipeline. In that case the first problem
> could be a bug in the resampling code in gst.
>
> The second problem could also happen if your equalizer is just so damn
> slow that it can't process enough audio as fast as required.

Well, I think it's unlikely because it seems to work ok with other
pipelines and no warnings on performance..

>
> The best place to do live processing with PA is really within the
> daemon. (Yes, I know that doing everything client-side is much easier in
> many ways. Until you run into the limits of the approach, that is.)
> Since you're doing equalization, module-equalizer-sink might already do
> what you want. If it's not good enough (I think it still has some
> strange problems on some hardware?), integrate your algorithm into
> module-virtual-sink like Pierre suggested.

Yes, I agree. The case is I wrote very tiny and code-beautiful app and
it's hugely difficult to reject it :) But still if the problems
persist I'll be forced to do.