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] redirect output to headless machine
On 10-07-07 05:42 PM, Simone Neugierig wrote: host2 (the client, where my headset is connected) in /etc/pulse/client.conf i added this line: default-source = 192.168.11.200 (host1) default-server = ... ? -Nathan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] redirect output to headless machine
host2 (the client, where my headset is connected) in /etc/pulse/client.conf i added this line: default-source = 192.168.11.200 (host1) default-server = ... ? -Nathan ive commented the default-source and set this instead: default-server = tcp:192.168.11.200:4713 still, the client side (host2) does not open a network connection to host1 -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support
here's a first work-in-progress set of patches. I managed to route iec958 formatted data through PulseAudio, works fine but there's still a lot to do. As discussed on the mailing list, I added a new flag to pa_stream connections, and also added a flag for the sink in case it can handle passthrough data. There's some logic to prevent silly connections but still allow for the same use cases as before: you can still mix and play PCM streams on a passthrough output, however you cannot connect nonaudio data to a regular sink, and likewise if a sink has already a connection you can only connect if both the existing inputs and the new one are PCM. Volume control is disabled only when a nonaudio stream is connected. You can give it a try by setting the 'Passthrough' configuration in pavucontrol and the following command line gst-launch filesrc location=file.ac3 ! ac3iec958 raw-audio=true ! pulsesink (note that pulsesink needs to be extended to handle the x-iec958 caps and set the NONAUDIO_IEC958 flag when needed, the mixing logic will not work with pulsesink). I still have to do some work on sample-rate and channel map adaptation, but comments are welcome at this point. Cheers - Pierre 0001-alsa-fix-mixer-profiles-add-passthrough-config.patch Description: Binary data 0002-AC3-passthrough-support.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
