SoapyRemote icon indicating copy to clipboard operation
SoapyRemote copied to clipboard

Fix scaling in CS16-CS8 conversion

Open zuckschwerdt opened this issue 4 years ago • 2 comments

Currently the CS16-CS8 conversion applies no scaling.

This works somewhat for "remoteFormat=CS8, localFormat=CS16" but since CS16 then isn't native there is no scaling info (just scale=128 for CS8) and a full-scale of 32768 is expected (rescaled by 256).

The other way around is somewhat worse, CS16 usually has a scale of 2048 or 32768 and going to CS8 without scaling clips the upper bits. It might work if the CS16 is a full-scale of 2048 and somewhat quiet. Also this might be pretty invisible as it's not a common use-case.

This change expects CS8 scaleFactor to be power of 2, usually 128 and uses an integer multiplication for fast and precise scaling. CS8 with a full-scale other than 128 is unexpected but the scaling will still work, with some minor rounding error perhaps.

The CS16 to CS8 scales with a fast integer division as more precission won't reflect in the resulting CS8. Rounding of the CS16 full-scale will work well with e.g. 2047.0 - 2048.0 or 32767.0 - 32768.0 to get a power of 2 as divisor.

Caveat: the CS8 to CS16 fix will affect consumers that (wrongly) assume that the native (remote) full-scale info applies to the localFormat -- but I don't known about any consumer with a hack like that? Also the CS16 to CS8 fix might lose information if the CS16 is not data according to the declared full-scale. Again that is broken behaviour and unlikely to exist.

zuckschwerdt avatar Jul 07 '21 09:07 zuckschwerdt

I think at the time I just intentionally ignored any fixed point to fixed point scaling. But it seems like the right idea.

I'm not too worried about the scaling change, other than that some folks make have become accustomed to transmit scaling on 16-bit CS16 samples for certain devices that had native CS8. But it seems like something acceptable to change in a release for the sake of consistency.

I can interest you in the highly exciting task of entirely switching these converters over to the converter API? Theres a set of conversions with scale factors waiting to be used: https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/ConverterRegistry.hpp

guruofquality avatar Jul 10 '21 15:07 guruofquality

Sure, I'll play around with that. I think I'll put the converter change on top of this, so people have a reference what changed in these two cases before everything vanished into converters :)

zuckschwerdt avatar Jul 10 '21 17:07 zuckschwerdt

I forgot about this PR, but let's merge as it only improves things.

zuckschwerdt avatar Jan 21 '24 13:01 zuckschwerdt