Re: [pulseaudio-discuss] Virtual device in Pulseaudio
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. 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). ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
My question is: is it possible to create a virtual device in Pulseaudio which has one input and one output and transfers stream from its input to the output? I tried different solutions including module-loopback (no success) and module-pipe-sink/source (gstreamer wasn't able to stream through it due to very low speed as I guess) but I have no success at all. Use module-virtual-sink, add your code for post-processing where indicated by the comments. It was written precisely for this type of use cases. Thank you, that's really the solution but I wanted to use equalizer plugin of GStreamer (or at least equalizer sink of PA) not to write yet another equalization code so it seems that adding post-processing code to the module isn't very good this way. Monitoring sink works ok for that but with issues... ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
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 2000 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?),
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
On Thu, 2010-07-01 at 16:14 +0100, Colin Guthrie wrote: While I don't know much about it, git master does have a kind of virtual device that is used for the new built in equaliser stuff. It may be that you could use that. Alternatively you could simply use a null sink (call it what you want, play your stuff to the null sink, then have a gst pipeline that records from the monitor source of that sink, does it's processing and then plays it back to a real sink. That should work OK if you can live with all the delays and inefficiences etc. such an approach creates. That etc contains also the buffering issues that are caused by clock drift... But whatever, apparently it's still good enough (unless Alexey is using the equalizer in git - his reply wasn't completely clear about this). -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
Colin, thank you very much! It works fine, the solution solves my problem brilliantly and delays and CPU load are quite ok. Even for Skype via PA their are normal to make voice call successfully. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Virtual device in Pulseaudio
Hello, I'm working at some global effect processing stuff, for example, equalizer which affects several my applications which output sound through Pulseaudio. I want to implement it using GStreamer and virtual soundcard which all the applications will output their sound to. E.g. we set some virtual PA device as output for every application, say devproc and some processing GStreamer application use this device as its input and transfers stream to 'real' PA device (which stands for real soundcard) through some effects. My question is: is it possible to create a virtual device in Pulseaudio which has one input and one output and transfers stream from its input to the output? I tried different solutions including module-loopback (no success) and module-pipe-sink/source (gstreamer wasn't able to stream through it due to very low speed as I guess) but I have no success at all. Thank you in advance. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual device in Pulseaudio
'Twas brillig, and 4ernov at 01/07/10 15:58 did gyre and gimble: Hello, I'm working at some global effect processing stuff, for example, equalizer which affects several my applications which output sound through Pulseaudio. I want to implement it using GStreamer and virtual soundcard which all the applications will output their sound to. E.g. we set some virtual PA device as output for every application, say devproc and some processing GStreamer application use this device as its input and transfers stream to 'real' PA device (which stands for real soundcard) through some effects. My question is: is it possible to create a virtual device in Pulseaudio which has one input and one output and transfers stream from its input to the output? I tried different solutions including module-loopback (no success) and module-pipe-sink/source (gstreamer wasn't able to stream through it due to very low speed as I guess) but I have no success at all. While I don't know much about it, git master does have a kind of virtual device that is used for the new built in equaliser stuff. It may be that you could use that. Alternatively you could simply use a null sink (call it what you want, play your stuff to the null sink, then have a gst pipeline that records from the monitor source of that sink, does it's processing and then plays it back to a real sink. That should work OK if you can live with all the delays and inefficiences etc. such an approach creates. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss