Open source speech codec designed for communications quality speech between 700 and 3200 bit/s. The main application is low bandwidth HF/VHF digital radio.
Currently several codebook files are generated at build time from .txt templates. This works well on Linux like systems, and means we "don't repeat ourselves) (DRY principal) but its a pain point for builds on other operating systems. It means that not all of the C files are present in the repo.
Lets consider/discuss having all C files present in the repo, and do the .txt -> .c conversion at "development time". The files are only updated very rarely (some haven't changed for a decade).
Might be worth waiting until the new modes have settled, or include this in other refactoring work.
Take into account the PLT policy "We have standardized on C99 and develop and test using gcc on a Linux platform". Does this proposal conflict with that? The main purpose of that policy to to prevent open ended maintenance of non C99/non-Linux builds that distract resources away from core work that only we can do.
This should be discussed by the development team, and a consensus reached, before any work is started.
Currently several codebook files are generated at build time from .txt templates. This works well on Linux like systems, and means we "don't repeat ourselves) (DRY principal) but its a pain point for builds on other operating systems. It means that not all of the C files are present in the repo.
Lets consider/discuss having all C files present in the repo, and do the .txt -> .c conversion at "development time". The files are only updated very rarely (some haven't changed for a decade).
Might be worth waiting until the new modes have settled, or include this in other refactoring work.
Take into account the PLT policy "We have standardized on C99 and develop and test using gcc on a Linux platform". Does this proposal conflict with that? The main purpose of that policy to to prevent open ended maintenance of non C99/non-Linux builds that distract resources away from core work that only we can do.
This should be discussed by the development team, and a consensus reached, before any work is started.