Room correction with convolution per sample rate

[digimuse]

Thanks for clarifying the exact sequence of operations, and pointing out the filter options.

I did not realize that ffmpeg automatically resamples a convolution file, if its sample rate does not match the file being transcoded.

I have the following configuration for MinimServer/Streamer on the Melco server.

Quote:minimserver-0.8-update-126.1
minimstreamer-0.7.10.2

stream.options:
convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S*.wav -lavfi afir=gtype=gn

stream.transcode:
flac(<352):wav;

I have .wav convolution files for 44 KHz to 384 KHz.

I tested this on Flac files 16/44, 24/48/24/88, 24/96, 24/176, 24/192, 24/352, 24/384, and .dsf files (DSD64, DSD128, and DSD256).

No convolution for dsf files, no convolution for 352 KHz and 384 KHz files - and no stuttering on the Melco. All other sample rates had the matching sample rate convolution filters applied (as indicated in the "verbose" log).

There was an error with 24/48 KHz files, which you mentioned is a bug with ffmpeg for armhf builds.

I also tried out the convolution operations on a Mac (more powerful processor, so stuttering is not an issue):

Quote:minimserver-0.8-update-126.1
minimstreamer-0.7.10.2

stream.options:
convOut=-i /Users/digimuse/Music/Convolution/Cor1S*.wav -lavfi afir=gtype=gn

stream.transcode:
flac:wav;, dsf:wav;

I had the same .wav convolution files for 44 KHz to 384 KHz for this setup.

I tested this on Flac files 16/44, 24/48/24/88, 24/96, 24/176, 24/192, 24/352, 24/384, and .dsf files (DSD64, DSD128, and DSD256).

All sample rates had the matching convolution filter applied (352 KHz for all dsf files), and there was no stuttering.

So the only remaining issue is ffmpeg for armhf builds.