[pulseaudio-discuss] Virtual sink to pipe audio stream to STDIN of shell-command?

[Rene Bartsch]

Am 2015-08-02 11:58, schrieb Alexander E. Patrakov:
> [All of the below is valid only if the results that I obtained for
> power consumption vs wakeup rate on my Sony VAIO VPC-Z23A4R laptop are
> an exception, not the rule]
> 
> 02.08.2015 14:23, Rene Bartsch wrote:
>> The next step would be to copy the convolver-code of BruteFIR to the
>> Pulseaudio-Github-repository and interface the code as a module.
> 
> Well, it is not that simple. Copying the code from BruteFIR won't be
> really acceptable, because of the following reason. PulseAudio tries
> to optimize wakeups by mixing audio in big chunks, speculatively. The
> result is valid only if nothing unexpected (such as a software volume
> change or a new stream) happens. So, PulseAudio sometimes (when the
> unexpected happens) needs to say to the filter: "forget the last N
> samples, here is a new version". Result: high average latency, low
> latency of reaction to external events.
> 
> BruteFIR code does not have a way to say this.
> 
> Yes, this does mean that different requirements are imposed on
> internal code (where rewindability is required when it is practical to
> implement), and on external code (where it is never practical). And
> for convolution, I'd say that writing rewindable code is practical,
> and it does not have to be based on the ideas from BruteFIR :)

I see. A "module-pipe-shell" seems to be a quick hack as Pulseaudio can 
asynchronously pipe chunks of data through an external 
convolver-application via STDIN/STDOUT and drop old samples/repeat 
updated samples. For a real convolver-module a developer is needed who 
has extensive knowledge of convolving and programming - and a lot of 
spare-time. ;)

Can you publish an appeal for that task?

I'm still stuck at getting a reliable convolver-workflow. Pulseaudio -> 
Jack -> BruteFIR/Jconvolver -> Jack -> ALSA seems to be complicated to 
configure with many different configuration files. My current workflow 
is Pulseaudio -> module_pipe_sink -> FIFO -> external sudo BruteFIR call 
-> ALSA. When I put source- and sink-mixing into one BruteFIR-instance 
(both in the same BruteFir-config-file), BruteFIR often quits with "ALSA 
I/O: overflow!" and "ALSA I/O: underflow!". Separate instances block 
each other on the ALSA device. Pluggable USB-audio-devices increase 
complexity, too. Convolving is new to me, but I didn't think it would 
become so complicated to apply REW-speaker-measurements to an 
audio-stream on a desktop-machine.

-- 
Best regards,

Renne