Hi David Thank you for your extensive test. So, your result suggests, that the Downsampling just makes jump the freedv_rx() over the time limit in my implementation. I can see, that the cpu cycles jump up also when using cohpsk directly. But for the time beeing, I will stay with 7500, because the nasty sound is unacceptable. When you find a quicker accquisition, I can try again with 8000.
Greetings Alfred On 08.02.2017 22:25, David Rowe wrote: > Hi Alfred, > > Here are two tests timing the operation of the cohpsk demodulator in > acquisition mode, i.e. trying to sync up on a signal. I'm feeding it > with a FreeDV 1600 signal so it will never sync up. > > 1/ In the first test we drive the cohpsk demod directly at 7500Hz: > > david@penetrator:~/codec2-dev/build_linux/src$ time ./cohpsk_demod > ~/Desktop/ve9qrp_1600.wav /dev/null > > real 0m23.950s > user 0m23.944s > sys 0m0.004sj > > 2/ In the second test we drive it through the freedv API, which includes > the 8000Hz to 7500Hz resampler: > > david@penetrator:~/codec2-dev/build_linux/src$ time ./freedv_rx 700C > ~/Desktop/ve9qrp_1600.wav /dev/null > > real 0m22.618s > user 0m22.612s > sys 0m0.004s > > It appears they execute in approximately the same time. This is > consistent with my previous tests - the CPU load appears to be in the > acquisition code of the cohpsk modem, not the 7500<->8000 resampler. > > Looking at the code this also makes sense - the resampler is fairly > simple from a CPU load point of view, there is much more going on with > the acquisition algorithm. > > Cheers, > > David > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
