Fix issue possibly degrading RADE RX audio quality. #804
Conversation
|
After a quick search, it seems that float gives 6 or 7 decimal places of precision, while double gives 15 digits. That could explain it, unless something changed in the compiler. |
My VM that I use for Windows builds got trashed recently so I had to rebuild it. It's possible that messed something up too (i.e. due to using a different llvm-mingw than before). Though I was also noticing higher loss on macOS before this change. Anyway, you didn't happen to notice any quality differences with this change, right? |
|
Between the October 18th release and this commit in early December: the way the incoming data is processed changed a bit, or so it seems. Personally I didn't notice much but then I keep running new code as it evolves so maybe the quality difference passed me by and off-air signals tend to be quite variable. I suppose Walter ought to try a build with this change and see if the speech quality is back to how it was originally. After seeing the comment closing drowe67/radae#41 are you going to merge this change? |
|
Might there be a connection with this issue #777 ? |
We'll probably have to do a third test build in light of the other reported bugs, so might as well.
If anything, that should have improved audio quality. |
Walter K5WH reported that the latest test build of 2.0 didn't sound as good on RADE as the 20241018 version. Using the RADE tools and the automated test framework, I recorded a loss of 0.182 between freedv-gui and
radae_rxin the RADE repo. After implementing the code change in this PR, the loss dropped to 0.001.(See companion issue drowe67/radae#41 indicating minimal loss between Python and C decoders.)