Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Room correction with convolution per sample rate
30-12-2018, 22:56 (This post was last modified: 30-12-2018 22:57 by simoncn.)
Post: #31
RE: Room correction with convolution per sample rate
I have been able to find a solution for the DSF issue and this is available for testing in the latest MinimStreamer test build 0.7.10.2.

MinimStreamer now detects that the input file is DSF and ensures that FFmpeg converts the DSD audio data from the input file into a 352800 Hz PCM stream before applying the convolution filter. If a 352800 Hz convolution filter is available, this is selected; if not, the convolution filter with the closest sample rate to 352800 Hz is selected instead.
Find all posts by this user
Quote this message in a reply
31-12-2018, 23:16
Post: #32
RE: Room correction with convolution per sample rate
I was able to successfully install "minimstreamer-0.7.10.2."

After restarting the server, the verbose log files indicated:
Quote:Convolution file for sample rate 352800 is /mnt/disk1/share/MinimServer/convolution/Cor1S352.wav
Convolution file for sample rate 44100 is /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav
Convolution file for sample rate 384000 is /mnt/disk1/share/MinimServer/convolution/Cor1S384.wav
Convolution file for sample rate 176400 is /mnt/disk1/share/MinimServer/convolution/Cor1S176.wav
Convolution file for sample rate 48000 is /mnt/disk1/share/MinimServer/convolution/Cor1S48.wav
Convolution file for sample rate 88200 is /mnt/disk1/share/MinimServer/convolution/Cor1S88.wav
Convolution file for sample rate 192000 is /mnt/disk1/share/MinimServer/convolution/Cor1S192.wav
Convolution file for sample rate 96000 is /mnt/disk1/share/MinimServer/convolution/Cor1S96.wav

I tried the following settings:
Quote:stream.options:
convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S*.wav -lavfi afir=gtype=gn

stream.transcode:
flac:wav;

Flac files at 16/44, 24/88, 24/96, 24/176, 24/192, 24/352, 24/384 - performed the convolution, and played without problem (except for the Melco stuttering at 24/352 and 24/384).

Flac files at 24./48 still had the error "Converter program ended unexpectedly with exit value 139". I realize you haven't got to this yet.

I was able to play a (DSD64) .dsf track, but no convolution operations were performed (the "verbose" logs did not indicate anything, and my DAC reported a DSD file). No problem with the Melco processor serving up unprocessed the DSD file.

This is good - if the user does not want to perform any convolution operations on DSD files, then none are performed.

Changing stream.transcode to:
Quote:flac:wav;, dsf:wav24;352

The same .dsf track played - with stutter (the Melco processor can't transcode in real-time at 352 KHz and above). My DAC also indicated 24/352 KHz track, and the log files showed:
Quote:Using convolution file /mnt/disk1/share/MinimServer/convolution/Cor1S352.wav for sample rate 352800

Changing stream.transcode to:
Quote:flac:wav;, dsf:wav24;176

The same .dsf track played - still with stutter. My DAC now indicated 24/176 KHz track, while the log files showed:
Quote:Using convolution file /mnt/disk1/share/MinimServer/convolution/Cor1S352.wav for sample rate 352800

Odd that the DAC and MinimStreamer disagree on the sample rate - but fortunately no errors were reported (unlike with minimstreamer-0.7.10.1). Maybe I'm doing something wrong.

On a related topic: Would it be possible to add a flag to not perform any convolution if there is not a file for the exact sample rate being played?

Applying a convolution file of the wrong sample rate may degrade the sound (In JRiver, if there is no convolution file with the same sample rate as the track being played, JRiver resamples the convolution file on the fly - see Automatic Resampling, and this discussion).

This also has the advantage that the user can decide what sample rates to perform the convolution on. For me, using the Melco server, I could remove all convolution files for 352 KHz and 384 KHz (the sample rates at which the Melco processor stutters).
Find all posts by this user
Quote this message in a reply
01-01-2019, 17:21
Post: #33
RE: Room correction with convolution per sample rate
Thanks very much for testing the new build and for your very helpful feedback.

When you set dsf:wav24;176 in stream.transcode and also enable convolution, the following is happening:

1) The DSD audio data is converted to PCM with a sample rate of 352800 Hz. This value is fixed and does not depend on the transcoding output sample rate in stream.transcode.

2) The output from step 1 is convolved using the 352800 Hz convolution filter file (or the closest sample rate available if this file is not found).

3) The output from step 2 is downsampled to 176400 Hz as specified by your stream.transcode setting.

This means that MinimStreamer is correctly using the 352800 Hz convolution filter file and your DAC is correctly reporting the sample rate of the stream that it receives as being 176400 Hz.

For comparision, the following is happening for a PCM audio stream:

1) Not applicable

2) The output from step 1 is convolved using the convolution filter file that exactly matches the sample rate of the PCM audio stream (or the closest sample rate available if this file is not found).

3) The output from step 2 is downsampled or upsampled if this is specified by your stream.transcode setting.

In step 2 (for both DSF and PCM input files), if MinimStreamer provides a convolution filter file that doesn't exactly match the sample rate of the audio data, FFmpeg automatically resamples the convolution filter file to the sample rate of the audio data, just like JRiver.

Because of this, I don't think MinimStreamer should prevent convolution if the convolution input file and audio stream don't have matching sample rates, as this would negate a useful feature of FFmpeg.

To prevent convolving 352800 Hz and 384000 Hz files because of the stuttering issue, you could use an input type filter in stream.transcode to prevent these sample rates from being transcoded. This assumes that your DAC can accept DSD audio input.
Find all posts by this user
Quote this message in a reply
01-01-2019, 22:29 (This post was last modified: 01-01-2019 22:30 by digimuse.)
Post: #34
RE: Room correction with convolution per sample rate
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.
Find all posts by this user
Quote this message in a reply
02-01-2019, 23:01
Post: #35
RE: Room correction with convolution per sample rate
Thanks for doing all this. I should have an opportunity to investigate the 48 kHz bug in the next few days.
Find all posts by this user
Quote this message in a reply
06-01-2019, 21:16
Post: #36
RE: Room correction with convolution per sample rate
I have found the cause of the 48 kHz problem. It isn't caused by a bug in FFmpeg and it isn't a problem with the ARM build.

The problem is caused by a hardware bug in the Marvell Armada 370 processor used by the Melco N1, N100 and N10. When the user specifies the gtype=gn option, the algorithm that FFmpeg uses to calculate the gain involves multiplying filter coefficients. For some values of filter coefficients, this multiplication can produce a floating-point underflow. Normally this underflow would be harmless but on the Armada 370 it causes register corruption and/or segmentation faults. I have verified this by single-stepping through the generated assembler instructions in a debugger. It just so happens that your 48 kHz filter contains coefficients that cause an underflow and trigger this problem.

To summarize, the problem occurs with the following combination:
1) gtype=gn
2) the Armada 370 processor
3) certain filter coefficient values

You can't do much about 2) or 3), but you could change 1) by replacing the gtype option with either the dry or wet option. I don't know which of these would be better; you would need to experiment.

I will report this problem to the FFmpeg developers. It may be that they are willing to change the FFmpeg code used for the gtype=gn gain calculation to avoid triggering the Armada 370 underflow bug. Even if they are willing to do this, it will be some time before this change becomes available in FFmpeg builds.
Find all posts by this user
Quote this message in a reply
08-01-2019, 08:11 (This post was last modified: 08-01-2019 08:13 by digimuse.)
Post: #37
RE: Room correction with convolution per sample rate
Wow! That must have been quite a task "single-stepping through the generated assembler instructions in a debugger." Thanks for figuring this out.

I tried out the "wet" settings (FFmpeg Filters Documentation), as this sets the final output gain. My convolution filters reduce the gain by around 6dB, so applying the gain to the output is probably safer than to the input (which might result in clipping). I have no idea what the arguments to "wet"/"dry" define (the valid range seems to be 0 to 10).

The setting I used for the Melco server are:

Quote:stream.options:
convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S*.wav -lavfi afir=wet=6

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

As before, 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). This time there were no errors - all flac files with sample rates less than 352 kHz had the convolution filters applied (no errors for 48 kHz sample rate files). I can now focus on evaluating the impact of the (different) convolution filters.

Thanks also for bringing this up with ffmeg developers.
Find all posts by this user
Quote this message in a reply
10-01-2019, 20:38
Post: #38
RE: Room correction with convolution per sample rate
The FFmpeg developers did not respond positively to my request for a change to work around this problem. For now, I will document that gtype=gn doesn't work on the Melco N1/N100/N10 and other machines containing the Armada 370
Find all posts by this user
Quote this message in a reply
11-01-2019, 04:41
Post: #39
RE: Room correction with convolution per sample rate
Thanks for trying to get the ffmpeg developers to come up with a fix for the Armada 370 problem. Too bad they weren't sympathetic.

Perhaps this is not a common problem, and if it does occur, it may be possible to use other convolution options, like "afir=wet=<0-10>" .
Find all posts by this user
Quote this message in a reply
11-01-2019, 10:05 (This post was last modified: 11-01-2019 12:38 by simoncn.)
Post: #40
RE: Room correction with convolution per sample rate
I have found that afir=wet=10 produces a satisfactory volume level while avoiding the Melco failure with gtype=gn that I have reported to the FFmpeg developers.. What we don't know is whether the Armada 370 hardware malfunction could affect the correct operation of FFmpeg in any other way. Please post here if you notice anything unexpected when running FFmpeg convolution on your Melco N1.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)