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
