[pulseaudio-discuss] Virtual device in Pulseaudio

[Tanu Kaskinen]

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?

> 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?

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.

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.

-- 
Tanu Kaskinen