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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
