Hi all, I'm now starting to look at the 700B mode, since that would be the next major advance for the SM1000. (All the little stuff that can be practically achieved has been achieved.)
I put this off until I got a better understanding of how the code worked. As I understand it, the structures for FreeDV are allocated on the heap using malloc, and that to switch modes, I must first free the existing instance and open a new one. > /* Set up FreeDV modem */ > f = freedv_open(FREEDV_MODE_700B); > n_samples = freedv_get_n_speech_samples(f); > n_samples_16k = 2*n_samples; > > short adc16k[FDMDV_OS_TAPS_16K+n_samples_16k]; > short dac16k[n_samples_16k]; > short adc8k[n_samples]; > short dac8k[FDMDV_OS_TAPS_8K+n_samples]; The n_samples bit concerns me though. That basically decides the size of the buffers used in encoding/decoding. Interestingly, we seem to be passing an integer non-const variable in the declaration of these arrays; didn't think that was allowed. (It clearly is here, then again, I've seen some like the TI Code Composer compiler which would definitely reject that bit of code.) These arrays get declared on the stack, so are going to be hard to change. We can pretend they are smaller, but not bigger. To my way of thinking, we have a couple of options: 1. We can use malloc/free to allocate these on the heap, which means we can re-allocate them later. 2. We can pick a size that will be big enough for both 700B and 1600, and leave them fixed at that size. 3. We allocate two sets of buffers, one for 700B, the other for 1600. Option 3 seems unwieldy in terms of code footprint and memory usage, so probably not worth considering. Option 2 would be the simplest, but I have no idea how big n_samples is, or how much it changes. Option 1 wouldn't be too hard, but I'm not sure what the implementation of malloc/free permits. Some embedded versions have funny restrictions like requiring you to free objects in the reverse order to their allocations. Some don't actually implement free(). Then there's the game of dealing with memory fragmentation. Each of those could bite us in unexpected ways. The other option is we just forgo giving the user a choice at run-time. The device stores the 700B/1600 mode selection in its configuration settings, and to change it requires a power-cycle to reboot. What's actually needed in order to switch from one mode to the other? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
