After downloading the zip files, unzip the files. The BroadVoice16™-related files will be extracted into the "BroadVoice16™" subdirectory. The file "BroadVoice16™.doc" in the "BroadVoice16™" subdirectory provides information about the BroadVoice16™ open source C code, such as the lower-level subdirectory structure, Microsoft Visual C++ project, Linux®/Solaris®/MKS directories, test scripts, test vectors, and a brief description of each source code file.
Similarly, the BroadVoice32™-related files will be extracted into the "BroadVoice32™" subdirectory, and the file "BroadVoice32™.doc" in the "BroadVoice32™" subdirectory provides necessary documentation about the BroadVoice32™ open source C code.
Note that prior to compiling fixed point code, fixed point operator library files from ITU-T need to be downloaded, see Section 5.1 of "BroadVoice16™.doc" and "BroadVoice32™.doc" within the respective archive for details.
Please note that as the maintainer of the official open source code bearing the trademarked "BroadVoice®" name, Broadcom intends to maintain the bit-stream compatibility (i.e., interoperability) between future versions of BroadVoice® open source code and the first version (version 1.0) of the BroadVoice® open source code. This is necessary in order to make sure future BroadVoice® open source code versions will be interoperable with existing BV16 and BV32 implementations. It is the responsibility of the code developers for future versions of BroadVoice® open source code to ensure that such interoperability with version 1.0 of BroadVoice® open source code is maintained.
By default the code is compiled (with G192BITSTREAM=1) to operate with a non-packed bit-stream format compliant with ITU-T G.192. This is a format convenient for channel impairment simulations, and it allows the use of tools typically used by the ITU-T for speech codec evaluations. It is only for offline simulation purposes. To produce a packed bit-stream for real-world communication purposes, compile with G192BITSTREAM=0. From version 1.1 onwards this will pack the bits according to RFC 4298 (regardless of endian format of processing platform).
On a little-endian platform, the change in version 1.1 to the packed bit-stream (only for G192BITSTREAM=0) means that the packed bit-stream of version 1.1 will be byte-swabbed when compared with version 1.0. On a big-endian platform there should be no difference. Additionally, there is no change for the non-packed G.192 bit-stream format, i.e. for G192BITSTREAM=1. To emphasize, the packed bit-stream of version 1.1 onwards is directly compliant with RFC 4298 regardless of endian format of processing platform. It is the responsibility of the implementer to verify that any bit-stream produced by his/her implementation for real-world communication purposes complies with RFC 4298.