On 08/25/2014 08:01 PM, Steve Underwood wrote:
That's not naive. Its a correct analysis. However, it means you need
quite a bit of extra storage, the compute needed to catch up on
demodulation when that is possible, and the compute needed to run a time
scaling algorithm as you catch up at the output. Do you have those
resources?
Well, David showed in his video that the SDR1000 is only taking 50% of
the CPU time to process during receive, which really beats the scary 90%
he had in earlier tests. So, the processing power might be even be
sufficient on that small a platform.
So, let's consider the storage. FDMDV_NOM_SAMPLES_PER_FRAME is 160, so
the nominal amount of 16-bit audio samples for a single frame is 320
bytes of storage. We need a "few" samples to sync up. I don't know how
many that is, but if it were 10, there would be 3200 bytes, and we can
pad it by another frame to have some room for time skew and make it
3520. And there would be an increase in code size - we don't know how
much yet.
Now, let's consider interpolation of the output audio to catch up in
time and thus reduce latency. In order to make it simple and to save on
computes, let's just decimate by throwing away 1 in every /n /samples.
Until we listen to that we won't know how bad it sounds, but perhaps it
isn't something anyone would notice. If it sounds bad, we might still
have enough CPU left for a more complicated interpolation.
Thanks
Bruce
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
