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
