Hi Steve,
Nice catch, I hadn't even thought to look in there! I used nm to check
the SM1000 .elf file and cos() and sin() are still linked in, despite
changing all calls in Codec 2 and fdmdv to cosf() and sinf(). This
could be the reason.
It does appear that the trig funcs are only called
Maybe replace all the FFT's with FHT's...
http://www.embedded.com/design/connectivity/4403178/Doing-Hartley-Smartly
I was also thinking, since you mentioned that the kiss code ran faster
than the ARM library, that maybe speed isn't the defining goal. That
is, if the ARM code is fast enough, and
Most demods require a few symbols to sync up. We often implement that
by delaying the output data. But once that happened you could have a 1
symbol latency.
On 26/08/14 10:19, Steve wrote:
I was thinking the next big thing (down the road) would be
full-duplex, and then you could have two
On 08/25/2014 07:35 PM, David Rowe wrote:
Most demods require a few symbols to sync up. We often implement that by
delaying the output data. But once that happened you could have a 1 symbol
latency.
Pardon my naïveté because I am obviously waving my hands about something
which others here
On 08/25/2014 11:23 PM, Steve wrote:
Maybe replace all the FFT's with FHT's...
http://www.embedded.com/design/connectivity/4403178/Doing-Hartley-Smartly
I was also thinking, since you mentioned that the kiss code ran faster
than the ARM library, that maybe speed isn't the defining goal. That
On 08/26/2014 10:46 AM, Bruce Perens wrote:
On 08/25/2014 07:35 PM, David Rowe wrote:
Most demods require a few symbols to sync up. We often implement that by
delaying the output data. But once that happened you could have a 1 symbol
latency.
Pardon my naïveté because I am obviously
with enough horsepower available people should keep in mind running
multiple parallel demods all running at an offset phase, saves on sync
time (as the likely 4x to 8x expense on processing power) .
On 26/08/2014 12:35 PM, David Rowe wrote:
Most demods require a few symbols to sync up. We
On 08/26/2014 12:21 PM, Bruce Perens wrote:
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
