Another option might be to have both: The new rawdatarx/rawdatatx functions use a continuous buffer of data bytes (with maybe the last one being incomplete) And we re-introduce the codecrx/codectx as functions to send/receive codec2 frames.
With a little bit of refactoring the overhead of both functions will be minimal. I'll have a go at it and see how hard it is. Regards, Jeroen On 07/06/2020 10:50 PM, David Rowe wrote: > Hi Jeroen, > >> The easiest would be to fix 700D to use the same pattern as the other modes. >> But maybe we should fix all of them to use the 700D pattern and make the >> rawdatarx/rawdatatx truly independent of any codec2 knowledge. >> @David, do you have a preference? > Perhaps the latter, however we still might find some of the modes don't > fill an integer number of bytes. > > Option 3 is we could just leave it for now, and let the API caller deal > with it. As explained in: > > https://github.com/drowe67/codec2/blob/master/README_data.md > > .... the idea of the raw data API was to support new HF data waveforms, > that will have much larger packet sizes, an integer number of bytes, and > other features that make them more suitable for production HF data > applications. So I just used the existing voice-oriented waveforms as a > placeholder for now. > > Cheers, > David > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
