interpretation delay parameter

[jvdh1978]

I have been using the tool after we added the DDRC88BM support in the dev build. One application for me is setting the delay for all channels (to do AV sync here). It seemed to not do much, so I looked at what happened: The communication of the plugin seems to specify the delay as an int for the amount of samples to delay, i.e. 1 second delay is being sent as the int 48000 (and it runs a 48kHz processing\sampling).

Currently the source code interpreted 1 as 0.1 millisecond and directly sends integers based on that, however I think that is coincedently almost corr3ect for a device with a sample rate of 96000 sampling, e.g. the HD devices.

A second issue is that the delay is hard limited to the value 80, but my device can go up to 48000. I here adjusted this level in minidsp\src\lib.rs, but maybe this should be a device dependent limit.

It is a bit over my head to suggest code differences this time for both issues :-).

[mrene]

I had initially taken these limits from the 2x4HD plugin. We can probably have a mode which is either "samples" or "time" in the device's config. Try out the delay-units branch.

[jvdh1978]

Yes that works nicely. Might I suggest to have the maximum delay also device dependent. Maybe it is unsafe to set it to u16:max. The plugin doesn't allow a setting higher then 48000 / 1s in my case. Second suggestion: maybe try high delay settings on the 2x4HD to confirm that it indeeds processes sent values as 0.01 ms/int and not samples (which is only slightly different: 1000/96000 = 0.0104 ms per int).

[mrene]

You are right. 80ms gets converted to 7680 by the 2x4hd's plugin, which is exactly what you'd expect for 96kHz - I can change everything to use sample counts instead.

[mrene]

This is now fixed in dev