pax_global_header00006660000000000000000000000064151142305610014510gustar00rootroot0000000000000052 comment=850bdb747b234d6a89f9547fbc6dfa1cf2a6722d videolan-libspatialaudio-2d42ddf/000077500000000000000000000000001511423056100171505ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/.github/000077500000000000000000000000001511423056100205105ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/.github/workflows/000077500000000000000000000000001511423056100225455ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/.github/workflows/cmake-multi-platform.yml000066400000000000000000000040171511423056100273240ustar00rootroot00000000000000name: CMake Build on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: runs-on: ${{ matrix.os }} strategy: # Set fail-fast to false to ensure that feedback is delivered for all matrix combinations. # Consider changing this to true when your workflow is stable. fail-fast: false # To add more build types (Release, Debug, RelWithDebInfo, etc.) customize the build_type list. matrix: os: [ubuntu-latest, windows-latest, macos-13, macos-latest] build_type: [Release] cpp_compiler: [g++, clang++, cl] include: - os: windows-latest c_compiler: cl cpp_compiler: cl - os: ubuntu-latest c_compiler: gcc cpp_compiler: g++ - os: ubuntu-latest c_compiler: clang cpp_compiler: clang++ - os: macos-13 c_compiler: clang cpp_compiler: clang++ - os: macos-latest c_compiler: clang cpp_compiler: clang++ exclude: - os: windows-latest cpp_compiler: g++ - os: windows-latest cpp_compiler: clang++ - os: ubuntu-latest cpp_compiler: cl - os: macos-13 cpp_compiler: cl - os: macos-13 cpp_compiler: g++ - os: macos-latest cpp_compiler: cl - os: macos-latest cpp_compiler: g++ steps: - uses: actions/checkout@v4 - name: Configure CMake run: > cmake -B ${{ github.workspace }}/build -DCMAKE_CXX_COMPILER=${{ matrix.cpp_compiler }} -DCMAKE_C_COMPILER=${{ matrix.c_compiler }} -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} -S ${{ github.workspace }} - name: Build run: cmake --build ${{ github.workspace }}/build --config ${{ matrix.build_type }} - name: Tests run: ctest --test-dir ${{ github.workspace }}/build --output-on-failure -C ${{ matrix.build_type }} videolan-libspatialaudio-2d42ddf/.github/workflows/meson-multi-platform.yml000066400000000000000000000053341511423056100273700ustar00rootroot00000000000000name: Meson Build on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: name: Build ${{ matrix.os }} (${{ matrix.cpp_compiler }}) runs-on: ${{ matrix.os }} strategy: # Set fail-fast to false to ensure that feedback is delivered for all matrix combinations. # Consider changing this to true when your workflow is stable. fail-fast: false # To add more build types (Release, Debug, RelWithDebInfo, etc.) customize the build_type list. matrix: os: [ubuntu-latest, windows-latest, macos-13, macos-latest] build_type: [Release] cpp_compiler: [g++, clang++, cl] meson_version: ["1.2.0"] include: - os: windows-latest c_compiler: cl cpp_compiler: cl - os: ubuntu-latest c_compiler: gcc cpp_compiler: g++ - os: ubuntu-latest c_compiler: clang cpp_compiler: clang++ - os: macos-13 c_compiler: clang cpp_compiler: clang++ - os: macos-latest c_compiler: clang cpp_compiler: clang++ exclude: - os: windows-latest cpp_compiler: g++ - os: windows-latest cpp_compiler: clang++ - os: ubuntu-latest cpp_compiler: cl - os: macos-13 cpp_compiler: cl - os: macos-13 cpp_compiler: g++ - os: macos-latest cpp_compiler: cl - os: macos-latest cpp_compiler: g++ steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.x' - name: Install dependencies run: python -m pip install meson==${{ matrix.meson_version }} ninja - name: Configure Project run: meson setup builddir/ env: CC: ${{ matrix.c_compiler }} CXX: ${{ matrix.cpp_compiler }} if: ${{ matrix.cpp_compiler != 'cl' }} - name: Configure Project (MSVC) run: meson setup --vsenv builddir/ env: CC: ${{ matrix.c_compiler }} CXX: ${{ matrix.cpp_compiler }} if: ${{ matrix.cpp_compiler == 'cl' }} - name: Build Project run: meson compile -C builddir/ env: CC: ${{ matrix.c_compiler }} CXX: ${{ matrix.cpp_compiler }} - name: Run Tests run: meson test -C builddir/ -v - name: Upload Test Log uses: actions/upload-artifact@v4 if: failure() with: name: ${{ matrix.os }}_${{ matrix.cpp_compiler }}_Meson_Testlog path: builddir/meson-logs/testlog.txt videolan-libspatialaudio-2d42ddf/.gitignore000066400000000000000000000006361511423056100211450ustar00rootroot00000000000000build/ install/ # Doxygen output **/docs/doxygen/html/ ## Core latex/pdflatex auxiliary files: *.aux *.lof *.log *.lot *.fls *.out *.toc *.fmt *.fot *.cb *.cb2 .*.lb ## Bibliography auxiliary files (bibtex/biblatex/biber): *.bbl *.bcf *.blg *-blx.aux *-blx.bib *.run.xml ## Build tool auxiliary files: *.fdb_latexmk *.synctex *.synctex(busy) *.synctex.gz *.synctex.gz(busy) *.pdfsync *.rubbercache rubber.cachevideolan-libspatialaudio-2d42ddf/.mailmap000066400000000000000000000000721511423056100205700ustar00rootroot00000000000000Peter Stitt videolan-libspatialaudio-2d42ddf/CMakeLists.txt000066400000000000000000000154351511423056100217200ustar00rootroot00000000000000cmake_minimum_required(VERSION 3.23) project(spatialaudio VERSION 0.4.0) # Options option(BUILD_SHARED_LIBS "Build shared instead of static libraries" ON) option(HAVE_MIT_HRTF "Should MIT HRTF be built-in" ON) include(GNUInstallDirs) set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") # Dependencies find_package(MySofa QUIET) # Get API version from header file(READ "include/SpatialaudioVersion.h" SPAUDIO_VER_HEADER) foreach(VERPART "MAJOR" "MINOR" "PATCH") if(SPAUDIO_VER_HEADER MATCHES "#define SPATIALAUDIO_API_VERSION_${VERPART} ([0-9]+)") set("SPAUDIO_API_${VERPART}" ${CMAKE_MATCH_1}) else() message(FATAL_ERROR "Unable to get SPATIALAUDIO_API_VERSION_${VERPART}") endif() endforeach() set(SPAUDIO_API "${SPAUDIO_API_MAJOR}.${SPAUDIO_API_MINOR}.${SPAUDIO_API_PATCH}") message(STATUS "libspatialaudio API version ${SPAUDIO_API}") set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS "include/SpatialaudioVersion.h") # Spatialaudio library add_library(spatialaudio) add_library(Spatialaudio::spatialaudio ALIAS spatialaudio) set_target_properties(spatialaudio PROPERTIES OUTPUT_NAME spatialaudio POSITION_INDEPENDENT_CODE ON VERSION "${SPAUDIO_API}" SOVERSION ${SPAUDIO_API_MAJOR} C_VISIBILITY_PRESET hidden CXX_VISIBILITY_PRESET hidden ) target_compile_features(spatialaudio PUBLIC cxx_std_14) target_sources(spatialaudio PRIVATE source/AmbisonicEncoder.cpp source/AmbisonicMicrophone.cpp source/AmbisonicCommons.cpp source/mit_hrtf/mit_hrtf_lib.c source/AmbisonicProcessor.cpp source/AmbisonicRotator.cpp source/AmbisonicDecoder.cpp source/AmbisonicBinauralizer.cpp source/AmbisonicSource.cpp source/AmbisonicShelfFilters.cpp source/AmbisonicOptimFilters.cpp source/hrtf/mit_hrtf.cpp source/hrtf/sofa_hrtf.cpp source/BFormat.cpp source/SpeakersBinauralizer.cpp source/kiss_fft/kiss_fftr.c source/kiss_fft/kiss_fft.c source/AmbisonicAllRAD.cpp source/AmbisonicBase.cpp source/AmbisonicSpeaker.cpp source/AmbisonicEncoderDist.cpp source/AmbisonicZoomer.cpp source/Decorrelator.cpp source/adm/DirectSpeakersGainCalc.cpp source/Renderer.cpp source/adm/AllocentricPannerGainCalc.cpp source/adm/AllocentricExtent.cpp source/adm/GainCalculator.cpp source/GainInterp.cpp source/PointSourcePannerGainCalc.cpp source/adm/PolarExtent.cpp source/RegionHandlers.cpp source/Screen.cpp source/ObjectPanner.cpp source/dsp/IIRFilter.cpp source/dsp/LinkwitzRileyIIR.cpp source/LoudspeakerLayouts.cpp PUBLIC FILE_SET HEADERS TYPE HEADERS BASE_DIRS include source FILES include/adm/Conversions.h include/adm/MappingRules.h include/adm/CartesianLoudspeakerLayouts.h include/adm/DirectSpeakersGainCalc.h include/RendererMetadata.h include/Renderer.h include/adm/AllocentricPannerGainCalc.h include/adm/AllocentricExtent.h include/AmbisonicAllRAD.h include/AmbisonicBase.h include/AmbisonicBinauralizer.h include/AmbisonicCommons.h include/AmbisonicDecoder.h include/AmbisonicEncoderDist.h include/AmbisonicEncoder.h include/AmbisonicMicrophone.h include/AmbisonicProcessor.h include/AmbisonicRotator.h include/Ambisonics.h include/AmbisonicShelfFilters.h include/AmbisonicOptimFilters.h include/AmbisonicSource.h include/AmbisonicSpeaker.h include/AmbisonicZoomer.h include/BFormat.h include/Coordinates.h include/Decorrelator.h include/adm/GainCalculator.h include/GainInterp.h include/hrtf/hrtf.h include/hrtf/mit_hrtf.h include/hrtf/sofa_hrtf.h include/LoudspeakerLayouts.h include/PointSourcePannerGainCalc.h include/adm/PolarExtent.h include/RegionHandlers.h include/Screen.h include/ScreenCommon.h include/SpeakersBinauralizer.h include/Tools.h include/ObjectPanner.h include/kiss_fft/kiss_fft.h include/kiss_fft/kiss_fftr.h include/dsp/IIRFilter.h include/dsp/LinkwitzRileyIIR.h include/SpatialaudioAPI.h include/SpatialaudioVersion.h ) # Generate config header set(SPATIALAUDIO_SUPPORTS_SOFA ${MYSOFA_FOUND}) set(SPATIALAUDIO_SUPPORTS_MIT_HRTF ${HAVE_MIT_HRTF}) if(NOT BUILD_SHARED_LIBS) set(SPATIALAUDIO_STATIC YES) endif() configure_file( "include/SpatialaudioConfig.h.in" "include/SpatialaudioConfig.h" ) target_sources(spatialaudio PUBLIC FILE_SET generated_headers TYPE HEADERS BASE_DIRS $/include FILES ${CMAKE_CURRENT_BINARY_DIR}/include/SpatialaudioConfig.h ) target_include_directories(spatialaudio PUBLIC $ ) target_compile_definitions(spatialaudio PRIVATE SPATIALAUDIO_COMPILATION ) if(MYSOFA_FOUND) message("Found mysofa!") set(MYSOFA_LIB "-L${MYSOFA_LIBRARY_DIRS} -lmysofa") set(MYSOFA_INCLUDE "-I${MYSOFA_INCLUDE_DIRS}") target_include_directories(spatialaudio PUBLIC ${MYSOFA_INCLUDE_DIRS}) target_link_libraries(spatialaudio ${MYSOFA_LIBRARIES}) endif(MYSOFA_FOUND) configure_file( "${CMAKE_CURRENT_SOURCE_DIR}/cmake/spatialaudio.pc.cmake" "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc" @ONLY ) install(TARGETS spatialaudio LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} FILE_SET HEADERS DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/spatialaudio FILE_SET generated_headers DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/spatialaudio ) install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc" DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig) install(FILES ${PROJECT_BINARY_DIR}/config.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/spatialaudio) enable_testing() add_subdirectory(tests) # Tarballs generation set(CPACK_PACKAGE_VERSION_MAJOR ${PROJECT_VERSION_MAJOR}) set(CPACK_PACKAGE_VERSION_MINOR ${PROJECT_VERSION_MINOR}) set(CPACK_PACKAGE_VERSION_PATCH ${PROJECT_VERSION_PATCH}) set(CPACK_SOURCE_PACKAGE_FILE_NAME "${CMAKE_PROJECT_NAME}-${PROJECT_VERSION}") set(CPACK_SOURCE_GENERATOR "TBZ2") list(APPEND CPACK_SOURCE_IGNORE_FILES "/build.*/" "/\\\\..+" ) include(CPack) videolan-libspatialaudio-2d42ddf/Changelog.md000066400000000000000000000117031511423056100213630ustar00rootroot00000000000000## Changes in 0.4.0 This release is a huge evolution for libspatialaudio from its origin as a Higher Order Ambisonics library. This new release expands functionality to include object-based audio, additional loudspeaker layout support, binauralizations and many more new features that makes this library ready for rendering all type of spatial audio. This is all unified in a Renderer class for Ambisonics, object-based audio, speaker layouts and binauralization. This makes it a much more comprehensive and easier to use library for immersive audio. The Renderer is designed to adapt easily to ADM and IAMF next‑generation audio workflows. ### Main Updates: Object-Based Audio: Position and render individual sources dynamically in 3D space, compatible with ITU ADM and AOM’s IAMF immersive audio standards. Unified Renderer Class: Seamlessly process HOA, object signals, speaker feeds, and binaural output under one API. Cross-Platform Builds: Modernized build system with Meson and CMake, ensuring reproducibility across different operating systems. Robust Documentation: Expanded theory, DSP background, and code examples for both newcomers and advanced developers. Real-time Improvements: The code is now more efficient and real-time safe, making it suitable for AR/AR and gaming applications. Higher Order Ambisonics (HOA): Efficiency and real-time improvements, as well as now supporting decoding to ITU standard loudspeaker layouts (5.1, 7.1.4, etc.) ### API changes - This is an API and ABI breaking release. - Move Classes to the `spaudio` namespace. - Simplified class names: - `CAdmDirectSpeakersGainCalc` to `AdmDirectSpeakersGainCalc` - `CAdmRenderer` to `Renderer` - `CAllocentricExtent` to `AllocentricExtent` - `CAllocentricPannerGainCalc` to `AllocentricPannerGainCalc` - `CAmbisonicAllRAD` to `AmbisonicAllRAD` - `CAmbisonicBase` to `AmbisonicBase` - `CAmbisonicBinauralizer` to `AmbisonicBinauralizer` - `CAmbisonicDecoder` to `AmbisonicDecoder` - `CAmbisonicEncoder` to `AmbisonicEncoder` - `CAmbisonicEncoderDist` to `AmbisonicEncoderDist` - `CAmbisonicMicrophone` to `AmbisonicMicrophone` - `CAmbisonicOptimFilters` to `AmbisonicOptimFilters` - `CAmbisonicPolarExtentHandler` to `AmbisonicPolarExtentHandler` - `CAmbisonicProcessor` to `AmbisonicProcessor` - `CAmbisonicRotator` to `AmbisonicRotator` - `CAmbisonicShelfFilters` to `AmbisonicShelfFilters` - `CAmbisonicSource` to `AmbisonicSource` - `CAmbisonicSpeaker` to `AmbisonicSpeaker` - `CAmbisonicSpreadPanner` to `AmbisonicSpreadPanner` - `CAmbisonicZoomer` to `AmbisonicZoomer` - `CBFormat` to `BFormat` - `CDecorrelator` to `Decorrelator` - `CGainCalculator` to `GainCalculator` - `CGainInterp` to `GainInterp` - `CIIRFilter` to `IIRFilter` - `CLinkwitzRileyIIR` to `LinkwitzRileyIIR` - `CPointSourcePannerGainCalc` to `PointSourcePannerGainCalc` - `CPolarExtentHandler` to `PolarExtentHandler` - `CPolarExtentHandlerBase` to `PolarExtentHandlerBase` - `CScreenEdgeLock` to `ScreenEdgeLockHandler` - `CScreenScaleHandler` to `ScreenScaleHandler` - `CSpreadPanner` to `SpreadPanner` - `CSpreadPannerBase` to `SpreadPannerBase` - Changed LFE handling for the Renderer (formerly AdmRenderer) when rendering to binaural. Before, LFE channels would be discarded when rendering to binaural, following the ADM specification. Now they are included and a new argument `useLfeBinaural` was added to `Configure`, to change this behaviour if necessary. - `OutputLayout` moved to the `LoutspeakerLayout.h` header. - Removed/replaced some OutputLayout entries: - Replaced `OutputLayout::ITU_0_2_0`, use `OutputLayout::Stereo` - Replaced `OutputLayout::ITU_0_5_0`, use `OutputLayout::FivePointOne` - Replaced `OutputLayout::ITU_2_5_0`, use `OutputLayout::FivePointOnePointTwo` - Replaced `OutputLayout::ITU_4_5_0`, use `OutputLayout::FivePointOnePointFour` - Replaced `OutputLayout::ITU_4_5_1`, use `OutputLayout::FivePointOnePointFourPlusLow` - Replaced `OutputLayout::ITU_3_7_0`, use `OutputLayout::SevenPointOnePointThree` - Replaced `OutputLayout::ITU_3_7_0`, use `OutputLayout::SevenPointOnePointThree` - Replaced `OutputLayout::ITU_4_9_0`, use `OutputLayout::ThirteenPointOne` - Replaced `OutputLayout::ITU_9_10_3`, use `OutputLayout::TwentyTwoPointTwo` - Replaced `OutputLayout::ITU_0_7_0`, use `OutputLayout::SevenPointOne` - Replaced `OutputLayout::ITU_4_7_0`, use `OutputLayout::SevenPointOnePointFour` - Replaced `OutputLayout::_3p1p2`, use `OutputLayout::ThreePointOnePointTwo` - Replaced `OutputLayout::_2_7_0`, use `OutputLayout::SevenPointOnePointTwo` - Removed `OutputLayout::FivePointZero` - Removed `OutputLayout::SevenPointZero` - CMake: Removed the `BUILD_STATIC_LIBS` option. Use the `BUILD_SHARED_LIBS` option to control if share or static libraries should be built. If both are needed, build twice explicitly. - The `config.h` header file was removed in favor of `SpatialaudioConfig.h` with properly prefixed defines to prevent name clashes. videolan-libspatialaudio-2d42ddf/LICENSE000066400000000000000000000654541511423056100201730ustar00rootroot00000000000000libspatialaudio is released under LGPLv2.1 (or later) and is also available under a commercial license. By contributing to this project, you allow VideoLabs to reship the unmodified code under a commercial license. You also allow VideoLAN and VideoLabs to relicense the project to a different open source license, never more restrictive than the LGPL (like a BSD/MIT/Apache license). === GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Libraries If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. , 1 April 1990 Ty Coon, President of Vice That's all there is to it! videolan-libspatialaudio-2d42ddf/README.md000066400000000000000000000121441511423056100204310ustar00rootroot00000000000000# Spatial audio encoding / decoding and binauralization library **libspatialaudio** is an open-source, real-time and cross-platform C++ library for spatial audio encoding, decoding and rendering. It provides a unified framework for working with different spatial audio formats and playback environments, from multichannel loudspeakers to headphones. At its core is the `Renderer` class, which brings together multiple spatial audio techniques under one umbrella. Whether you are working with Ambisonics (HOA), audio objects, direct speaker feeds (e.g. 5.1/7.1), or binaural rendering, the `Renderer` provides a consistent interface for rendering multiple different streams. Originally forked from **ambisonic-lib** by Aristotel Digenis it was expanded to support Higher Order Ambisonics *HOA* (**ACN/SN3D**) Ambisonics audio streams following the **Google spatial audio** specification: and the **IETF codec Ambisonics** specification It has since been expanded to include Object and speaker rendering, making it a more general purpose spatial audio library. These additions allow it to be used to render ITU Audio Definition Model **ADM** feeds (based on Rec. ITU-R BS.2127-1) and Alliance for Open Media's Immersive Audio and Formats **IAMF**. ## What You Can Do with libspatialaudio **libspatialaudio** contains classes for implementing different spatial audio techniques and processing: - **Ambisonics**: Encode, rotate, zoom, and decode HOA (up to 3rd order). Includes psychoacoustic optimizations for improved spatial perception. For more details on the Ambisonics capabilities of **libspatialaudio** please go [here](docs/AmbisonicsOverview.md). - **Object-based Audio**: Encode and position individual sound sources in 3D space, rendered to speakers or headphones. Read more on how to spatialise object signals [here](docs/ObjectPanning.md). - **Speaker Rendering**: Decode and route speaker streams or layouts to chosen output loudspeaker layouts. For a guide on how to render speaker signals see [here](docs/RendererOverview.md). - **Binaural Rendering**: Render immersive audio for headphones using HRTFs (either custom SOFA files or the included MIT HRTF). Works with Ambisonics, object-based audio, or multichannel speaker layouts (5.1, 7.1, etc.). Read more on how to binauralise loudspeaker signals [here](docs/LoudspeakerBinauralization.md). ## Applications While **libspatialaudio** is designed around core processing types rather than specific standards, it can be applied in workflows that use formats such as: - **ADM (Audio Definition Model)**: for metadata-driven rendering of objects, speakers and HOA. - **IAMF (Immersive Audio Model and Format)**: for next-generation immersive audio delivery. Both of these application use the `Renderer` class to interpret metadata and route signals appropriately, whether for loudspeaker layouts or binaural output. ## Features - Unified `Renderer` class for HOA, Object, Speaker, and Binaural processing. - Ambisonics encoding, processing and decoding up to 3rd order (ACN/SN3D). - Loudspeaker rendering to ITU and custom layouts. - Binauralization with SOFA-based or built-in HRTFs. - Object-based rendering with dynamic positioning. - Suitable for both real-time and offline rendering workflows. - Cross-platform C++ implementation. ## Learning About libspatialaudio The documentation includes: - background theory (mathematical, psychoacoustic, DSP) - All background theory sections have been written such that it should be accessible to anyone with some mathematical background. However, even without a mathematical background you should still be able to follow what is going on. - implementation details (lays out the choices made while writing the library). - code examples (overviews of the main classes and code examples). To learn more about the Ambisonics processors start [here](docs/AmbisonicsOverview.md). To learn more about the main `Renderer` start [here](docs/AdmRendererOverview.md). These two documents provide full examples of both signal flows, as well as links to more details for those who want to learn more or get more specific details. For those who do not need to know the background theory, most documentation pages contain a link at the top to take you directly to details of the code, as well as an example of how to implement it. ## Building libspatialaudio Clone the repository (if you haven't already): ```bash git clone https://github.com/videolabs/libspatialaudio.git cd libspatialaudio ``` To build **libspatialaudio**, either Meson or CMake can be used: ### Meson 1. Create a `build` directory and configure the project: ```bash meson setup build ``` 2. Build the project: ```bash meson compile -C build ``` ### CMake 1. Create a `build` directory and configure the project: ```bash cmake -B build ``` 2. Build the project: ```bash cmake --build build ``` ## License libspatialaudio is released under LGPLv2.1 (or later) and is also available under a commercial license. For full details see [here](LICENSE). videolan-libspatialaudio-2d42ddf/cmake/000077500000000000000000000000001511423056100202305ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/cmake/Modules/000077500000000000000000000000001511423056100216405ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/cmake/Modules/FindMySofa.cmake000066400000000000000000000027401511423056100246440ustar00rootroot00000000000000# Try to find libMySofa headers and library. # # Usage of this module as follows: # # find_package(MySofa) # # Variables used by this module, they can change the default behaviour and need # to be set before calling find_package: # # MYSOFA_ROOT_DIR Set this variable to the root installation of # libMySofa if the module has problems finding the # proper installation path. # # Variables defined by this module: # # MYSOFA_FOUND System has libMySofa library/headers. # MYSOFA_LIBRARIES The libMySofa library. # MYSOFA_INCLUDE_DIRS The location of libMySofa headers. find_package(PkgConfig QUIET) if(PKG_CONFIG_FOUND) pkg_check_modules(MYSOFA libmysofa) endif(PKG_CONFIG_FOUND) if(MYSOFA) set(MYSOFA_INCLUDE_DIRS ${MYSOFA_PKG_CONFIG_INCLUDE_DIRS}) set(MYSOFA_LIBRARY_DIRS ${MYSOFA_PKG_CONFIG_LIBRARY_DIRS}) endif() if(NOT MYSOFA_LIBRARIES) find_library(MYSOFA_LIBRARIES NAMES mysofa ) endif(NOT MYSOFA_LIBRARIES) if(NOT MYSOFA_LIBRARY_DIRS) find_path(MYSOFA_LIBRARY_DIRS NAMES libmysofa.so ) endif(NOT MYSOFA_LIBRARY_DIRS) if(NOT MYSOFA_INCLUDE_DIRS) find_path(MYSOFA_INCLUDE_DIRS NAMES mysofa.h ) endif(NOT MYSOFA_INCLUDE_DIRS) include(FindPackageHandleStandardArgs) find_package_handle_standard_args(MySofa DEFAULT_MSG MYSOFA_LIBRARIES MYSOFA_INCLUDE_DIRS ) mark_as_advanced( MYSOFA_LIBRARIES MYSOFA_INCLUDE_DIRS ) videolan-libspatialaudio-2d42ddf/cmake/spatialaudio.pc.cmake000066400000000000000000000004361511423056100243150ustar00rootroot00000000000000prefix=@CMAKE_INSTALL_PREFIX@ libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@ includedir=${prefix}/include Name: spatialaudio Description: Spatial audio rendering library Version: @PROJECT_VERSION@ Libs: -L${libdir} -lspatialaudio @MYSOFA_LIB@ -lm -lz Cflags: -I${includedir} @MYSOFA_INCLUDE@ videolan-libspatialaudio-2d42ddf/docs/000077500000000000000000000000001511423056100201005ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/docs/AmbisonicBinauralization.md000066400000000000000000000231011511423056100253770ustar00rootroot00000000000000# Ambisonic Decoding to Binaural If you are not interested in the theory you can read about how to use `AmbisonicBinauralizer` [here](#ambisonicbinauralizer). ## Theory and Implementation Details There are several methods for decoding from Ambisonics to binaural [[1](#ref1), [2](#ref2), [3](#ref3)]. In general, decoding is performed by convolution of the ambisonic signal with a matrix of filters. `AmbisonicBinauralizer` uses a virtual-speaker approach [[1]](#ref1). The virtual loudspeaker approach essentially decodes the signal to known loudspeaker layout and then applies an HRTF to each of the loudspeakers, which are summed to make the final 2-channel binaural output. This requires $2\times M$ convolutions, where $M$ is the number of virtual loudspeakers. In order to reduce the number of convolutions the HRTF of each virtual speaker is scaled by the corresponding ambisonic gains and summed to create a filter for each spherical harmonic. For an HRIR of length $k$ samples this is calculated using ```math \mathbf{Z}_{N,ear}^{\mathrm{bin}} = \frac{1}{\sqrt{M}} \left[ \tilde{\textbf{y}}_{N}(\theta_{1}, \phi_{1}), \tilde{\textbf{y}}_{N}(\theta_{2}, \phi_{2}), \ldots, \tilde{\textbf{y}}_{N}(\theta_{M}, \phi_{M}) \right] \mathbf{H}_{\mathrm{ear}} ``` where $`\mathbf{Z}_{N,ear}^{\mathrm{bin}}`$ is a matrix of size $`(N+1)^{2} \times k`$ containing the spherical harmonic decomposition of the loudspeaker array HRIRs, $`\mathbf{H}_{\mathrm{ear}}`$ is an $`M\times k`$ matrix containing the HRIRs corresponding to each of the loudspeaker directions for the left or right ear. This leads to $2\times (N + 1)^2$ convolutions which can be calculated using ```math x_{\mathrm{bin}}^{ear}(t) = \sum_{i = 0}^{(N+1)^{2}} q_{i} z_{i}^{ear}(t) \circledast b_{i}(t) ``` where $`z_{i}^{ear}(t)`$ is the filter in the $`i`$-th row of $`\mathbf{Z}_{\mathrm{N,ear}}^{\mathrm{bin}}`$, $`b_{i}(t)`$ is the $i$-th term in the ambisonic signal $`\textbf{b}_{N}(t)`$, and $`q_{i}`$ is the $i$-th element of $`\mathbf{q}_{N}`$ which contains gains that convert the input signal from SN3D to N3D. The number of convolutions can be reduced further to only $(N+1)^2$ convolutions if the head is assumed to be symmetric [[4]](#ref4). This is done by calculating the convolutions in the above equation for one ear and storing them. They are summed for the first ear directly. For the opposite ear the spherical harmonics that are left-right symmetric have their polarity inverted and before being summed. ### Virtual Loudspeaker Layout Choices For first-order signals `AmbisonicBinauralizer` uses a virtual layout on the vertices of a cube (8 virtual loudspeakers). For second- and third-order a virtual layout on the vertices of a dodecahedron (20 virtual loudspeakers) is used. Therefore, in both cases, preprocessing the HRTFs reduces the number of convolutions required (from 8 to 4 for first-order and 20 to 9 or 16 for second- and third-order respectively). This meets a requirement of `libspatialaudio` to minimise its CPU use. A cube was chosen for first-order because it is a mathematically ideal layout for this order. The dodocahedron was chosen because it provides good results for second- and third-order order and 8 of its 20 loudspeaker directions coincide directly with the cube layout. This allows for the number of HRTFs stored for both layouts to be only 20, meeting a requirement that `libspatialaudio` be lightweight. ![The quality measures for a basic decoder (top row) and max $`r_{\mathrm{E}}`$ decoder (bottom row) as a function of the source direction across the whole sphere for a third-order decoding to a dodecahedral loudspeaker array. The directions of the loudspeakers are shown as red circles.](images/dodeca_decoder.png) The above figure shows the total loudspeaker gain and energy for the dodecahedron for third-order (first- and second-order are now shown because they have equal performance for all source directions). It also shows the difference between the panning direction and velocity and energy vectors [[5]](#ref5), representing a prediction of perceived direction for low and high frequencies respectively. Finally, it also shows the velocity and energy vector magnitudes, for which a value of 1 is ideal (although an energy vector magnitude of 1 is not possible for a sound source reproduced by more than one loudspeaker). The figure shows that both amplitude and energy are constant for all source directions. This is ensures that there are no unwanted changes in level for different source directions. The velocity vector has perfect localisation and magnitude, indicating that at low frequencies the decoder is also performing ideally. The max $r_{\mathrm{E}}$ decoder for high frequencies shows small deviations between the source direction and the energy vector prediction. However, the maximum error is only 6.5\deg. The energy vector magnitude also exhibits some variation with source position. This may result in small variations in the perceived source width, but this effect will be small. ### Psychoacoustic Optimisation As outlined [here](AmbisonicOptimisation.md) shelf filtering can be applied to Ambisonics signal so that they are decoded in a psychoacoustically optimised manner. ## AmbisonicBinauralizer ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: A bool to indicate if the signal is to be decoded is 2D (azimuth only) or 3D (azimuth and elevation). - **nBlockSize**: The maximum number of samples the decoder is expected to process at a time. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **tailLength**: The value is replaced with the length of the HRIRs used for the binauralisation. - **HRTFPath**: An optional path to the .SOFA file containing the HRTF. If no path is supplied and the `HAVE_MIT_HRTF` compiler flag is used then the MIT HRTF will be used. - **lowCpuMode**: (Optional) If this is set to true (its default value) then the symmetric head assumption is used to reduce CPU used [[4]](#ref4). > [!IMPORTANT] > When libspatialaudios internal MIT HRTF is used instead of SOFA, binauralization > will only work for 1st order ambisonic, not for HOA like 2nd or 3rd order. ### Decoding a Signal A B-format signal can be decoded to the binaural signals using the `Process()` function. The processing is non-replacing, so the original B-format signal is unchanged and the decoded signal is contained in the output array. The inputs are: - **pBFSrc**: A pointer to the source B-format signal. - **ppDst**: Array of pointers of size 2 x nSamples containing the binaurally decoded signal. - **nSamples**: (Optional) The length of the input signal in samples. If this is not supplied then `nBlockSize` samples are assumed. ### Code Example This example shows how to decode an Ambisonics signal to a binaural. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = (float)M_PI * 0.5f; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the binaural decoder AmbisonicBinauralizer myDecoder; unsigned int tailLength = 0; myDecoder.Configure(nOrder, true, sampleRate, nBlockLength, tailLength); // Configure buffers to hold the decoded signal const unsigned int nEar = 2; float** earOut = new float* [nEar]; for (int iEar = 0; iEar < nEar; ++iEar) earOut[iEar] = new float[nBlockLength]; // Decode the Ambisonics signal myDecoder.Process(&myBFormat, earOut, nBlockLength); // Cleanup for (unsigned iEar = 0; iEar < nEar; ++iEar) delete[] earOut[iEar]; delete[] earOut; ``` ## References [1] Markus Noisternig, Alois Sontacchi, Thomas Musil, and Robert Höldrich. A 3D Ambisonic Based Binaural Sound Reproduction System. In 24th International Conference of the Audio Engineering Society, pages 1-5, June 2003. [2] Christian Schörkhuber, Markus Zaunschirm, and Robert Höldrich. Binaural rendering of ambisonic signals via magnitude least squares. In Proceedings of the DAGA, volume 44, pages 339-342, 2018. [3] Markus Zaunschirm, Christian Schörkhuber, and Robert Höldrich. Binaural rendering of Ambisonic signals by head-related impulse response time alignment and a diffuseness constraint. The Journal of the Acoustical Society of America, 143(6):3616-3627, 2018. ISSN 0001-4966. doi:10.1121/1.5040489. [4] Archontis Politis and David Poirier-Quinot. JSAmbisonics: A web audio library for interactive spatial sound processing on the web. In Interactive Audio Systems Symposium, 2016. [5] Michael Gerzon. General metatheory of auditory localisation. In 92nd Convention of the Audio Engineering Society, Vienna, March 1992. videolan-libspatialaudio-2d42ddf/docs/AmbisonicDecoding.md000066400000000000000000000370511511423056100237710ustar00rootroot00000000000000# Ambisonic Decoding to Loudspeakers If you are not interested in the theory you can read about how to use `AmbisonicDecoder` [here](#ambisonicdecoder) and `AmbisonicAllRAD` [here](#ambisonicallrad). ## Theory and Implementation Details An ambisonic signal cannot be played back directly. A decoder is required to convert the signal from the spherical harmonic representation to either loudspeaker signals (implemented in `AmbisonicDecoder` and `AmbisonicAllRAD`) or headphone signals (implemented in `AmbisonicBinauralizer`). An ambisonic signal of order $N$ can be decoded to a set of loudspeakers using a decoding matrix $`\textbf{D}_{N}^{\mathrm{SN3D}}`$ which has size $`M \times (N+1)^2`$ where $`M`$ is the total number of loudspeakers. The output loudspeaker signal $`\textbf{x}(t)`$ is given by ```math \textbf{x}(t) = \textbf{D}_{N}^{\mathrm{SN3D}} \textbf{b}_{N}(t). ``` The decoding matrix can be calculated using a number of different methods [[1](#ref1), [2](#ref2), [3](#ref3)]. If the loudspeaker layout is regularly distributed on a sphere then decoding can be performed simply by sampling the ambisonic signal at each of the directions of the loudspeakers, known as a sampling ambisonic decoder (SAD) [[4]](#ref4). The sampling decoding matrix $`\textbf{D}_{N}`$ is ```math \textbf{D}_{N}^{\mathrm{SN3D}} = \frac{1}{\sqrt{M}} \left[ \tilde{\textbf{y}}_{N}(\theta_{1}, \phi_{1}), \tilde{\textbf{y}}_{N}(\theta_{2}, \phi_{2}), \ldots, \tilde{\textbf{y}}_{N}(\theta_{M}, \phi_{M}) \right]^{\mathrm{T}}\mathrm{diag}(\textbf{q}_{N}) = \frac{1}{\sqrt{M}} \tilde{\textbf{Y}}_{N}^{\mathrm{T}}\mathrm{diag}(\textbf{q}_{N}) ``` where $`\tilde{\textbf{y}}_{\texttt{N}}(\theta_{m}, \phi_{m})`$ is the vector of spherical harmonics of the $m$-th loudspeaker direction **with N3D normalisation** and $`\textbf{q}_{\texttt{N}}`$ is a vector of gains to convert $`\textbf{b}_{N}(t)`$ from SN3D to N3D normalisation. ### Decoding to Irregular Loudspeaker Layouts Using Non-Linear Optimisation If the layout is irregular, such as the ITU 5.1 and 7.1 layouts, then finding a suitable decoding method becomes more complex. A significant limitation is that most decoder calculation methods require at least as many loudspeakers as there are ambisonic channels. This limits 5.1 to first-order. Wiggins [[5]](#ref5) used an optimisation technique that uses the Gerzon velocity and energy vectors [[6]](#ref6), along with the total pressure and energy sum of the loudspeaker gains, to calculate an optimised decoder for the 5.1 layout. Due to the optimisation method the higher order spherical harmonics are able to contribute, meaning decoders can be obtained for first- to third-order. The 5.1 decoders in `libspatialaudio` were kindly provided by Bruce Wiggins. The decoders for the 7.1 layout were generated using a method inspired by the non-linear optimisation work of Wiggins. A decoder derived in the manner should not have [psychoacoustic optimisation](AmbisonicOptimisation.md) gains or filters applied since the desired optimisations were factored into the decoder optimisation. ![Graphs showing the loudspeaker gains as a function of source direction for 5.1 and 7.1 layouts from 1st to 3rd order.](images/irregular_layout_gain_comparison.png) The above figure shows the gains of each of the loudspeakers for the 5.1 and 7.1 arrays for the orders 1 to 3 with the decoders in `libspatialaudio`. The use of higher-order harmonics is particularly evident in the asymmetric shape of the two rear-surround speakers of the 5.1 layout for third-order. ![Graphs showing the total level for 5.1 and 7.1 layouts as a function of source direction from 1st to 3rd order.](images/irregular_layout_level_variation.png) This figure shows the mean level of the decoders for sources around the horizontal. The 1st, 2nd and 3rd order levels are shown by the blue, red and yellow lines respectively. It shows that there is in a small level variation with source position around the horizontal at most 3.5 dB for the third-order 5.1 decoder. Consistent level across source directions is important in maintaining the balance of the sound scene when several sources have been panned to different directions. ### Decoding to Irregular Loudspeaker Layouts Using AllRAD The AllRAD method [[1]](#ref1) first decodes the signal to a spherically regular t-design virtual loudspeaker layout and then uses VBAP [[7]](#ref7) to pan the virtual loudspeakers to the real layout. The aim is to allow for optimal decoding to the virtual loudspeaker layout and then to spatialise this with a robust panning algorithm. Additional imaginary loudspeakers can also be included in the main real loudspeaker layout to help when decoding to, for example, a dome. The AllRAD method is the preferred decoding method of the EBU Audio Definition Model renderer (Recommendation ITU-R BS.2127-1) and Alliance For Open Media's Immersive Audio Model and Formats (IAMF) specification (). ## AmbisonicDecoder `AmbisonicDecoder` decodes an Ambisonics signal to either predefined or custom layouts using one of several methods: - the SAD method: sampling at each of the specified loudspeaker directions. This is suboptimal for any layout that is not regular on the sphere. - optimised decoder: the 5.1 and 7.1 preset layouts use the non-linearly optimised decoder matrices described above, since the SAD method is particularly unsuited to these layouts. The preset decoder matrices are loaded automatically if either of those layouts are selected or if a custom array that matches the directions is defined. - user decoder definition: the user can define the decoder matrix coefficients directly for the specified layout. This means the class can be used with any decoding method that the user requires. See [here](#cambisonicdecoder-set-custom-decoder-coefficients) for more details on how to set a custom decoder matrix. When a decoder matrix other than one of the presets is used `AmbisonicDecoder` applies shelf filtering to psychoacoustically optimise the decoded signal. Read more about psyschoacoustic optimisation [here](AmbisonicOptimisation.md). ### AmbisonicDecoder: Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: A bool to indicate if the signal is to be decoded is 2D (azimuth only) or 3D (azimuth and elevation). - **nBlockSize**: The maximum number of samples the decoder is expected to process at a time. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **nSpeakerSetup**: Choice of loudspeaker layout from one of the predefined options or to indicate use of a custom layout. Note that the 5.1 and 7.1 layouts **do not** use the ITU ordering. They use L/R/Ls/Rs/C/LFE and L/R/Ls/Rs/Lr/Rr/C/LFE respectively. This matches the channel ordering in VLC media player. - **nSpeakers**: The total number of loudspeakers if a custom layout is used. This is ignored if one of the predefined layouts is selected. ### AmbisonicDecoder: Set Custom Decoder Coefficients The `SetCoefficient()` function can be used to define a custom decoder for the currently selected layout. The parameters are: - **nSpeaker**: The index of the loudspeaker for which the coefficient is to be set. - **nChannel**: The index of the corresponding Ambisonic channel for which the coefficient is to be set. - **fCoeff**: The decoder matrix coefficient. The following code will set the decoder matrix to hold the values stored in `myDecMat`. ```c++ for (int iSpeaker = 0; iSpeaker < nLdspk; ++iSpeaker) for (int iCoeff = 0; iCoeff < nAmbiComponents; ++iCoeff) { myDecoder.SetCoefficients(iSpeaker, iCoeff, myDecMat[iSpeaker][iCoeff]); } ``` **Note**: Calling `Refresh()` will overwrite any coefficients set in this way and replace them with the default values for the selected layout (either a SAD matrix or a preset). ### AmbisonicDecoder: Decoding a Signal A B-format signal can be decoded to the loudspeaker signals using the `Process()` function. The processing is non-replacing, so the original B-format signal is unchanged and the decoded signal is contained in the output array. The inputs are: - **pBFSrc**: A pointer to the source B-format signal. - **nSamples**: The length of the input signal in samples. - **ppDst**: Array of pointers of size nLdspk x nSamples containing the decoded signal. ### AmbisonicDecoder Code Example This example shows how to decode an Ambisonics signal to a 5.1 loudspeaker layout. It loads the optimised preset decoder for this layout automatically. ```c++ #include "Ambisonics.h" const unsigned int sampleRate = 48000; const int nBlockLength = 512; using namespace spaudio; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the decoder for a 5.1 layout AmbisonicDecoder myDecoder; myDecoder.Configure(nOrder, true, nBlockLength, sampleRate, Amblib_SpeakerSetUps::kAmblib_51); // Configure buffers to hold the decoded signal const unsigned int nLdspk = myDecoder.GetSpeakerCount(); float** ldspkOut = new float* [nLdspk]; for (int iLdspk = 0; iLdspk < nLdspk; ++iLdspk) ldspkOut[iLdspk] = new float[nBlockLength]; // Decode the Ambisonics signal myDecoder.Process(&myBFormat, nBlockLength, ldspkOut); // Cleanup for (unsigned iLdspk = 0; iLdspk < nLdspk; ++iLdspk) delete[] ldspkOut[iLdspk]; delete[] ldspkOut; ``` ## AmbisonicAllRAD `AmbisonicAllRAD` decodes an Ambisonics signal to a layout defined in the ADM renderer specification (Recommendation ITU-R BS.2127-1) and AOM's IAMF specification (). It does not currently support decoding to arbitrary loudspeaker layouts. `AmbisonicAllRAD` optionally applies shelf filtering to psychoacoustically optimise the decoded signal. Read more about psychoacoustic optimisation [here](AmbisonicOptimisation.md). ### AmbisonicAllRAD: Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **nBlockSize**: The maximum number of samples the decoder is expected to process at a time. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **layoutName**: The name of the loudspeaker layout. This must be one of those specified in the ADM or IAMF specifications. The valid names are: - `"0+2+0"`: BS.2051-3 System A (Stereo) - `"0+4+0"`: Quad - `"0+5+0"`: BS.2051-3 System B (5.1) - `"2+5+0"`: BS.2051-3 System C (5.1.2) - `"4+5+0"`: BS.2051-3 System D (5.1.4) - `"4+5+1"`: BS.2051-3 System E - `"3+7+0"`: BS.2051-3 System F - `"4+9+0"`: BS.2051-3 System G - `"9+10+3"`: BS.2051-3 System H - `"0+7+0"`: BS.2051-3 System I (7.1) - `"4+7+0"`: BS.2051-3 System J (7.1.4) - `"2+7+0"`: 7.1.2 (IAMF v1.0.0-errata) - `"2+3+0"`: 3.1.2 (IAMF v1.0.0-errata) - `"9+10+5"`: EBU Tech 3369 (BEAR) 9+10+5 - 9+10+3 with LFE1 & LFE2 removed and B+135 & B-135 added - **useLFE**: If `true` then the decoded signal will include the LFE channels. If `false` then the LFE channels will be excluded i.e. a `0+5+0` (5.1) signal will be output as a 5-channel signal instead of a 6-channel one. - **useOptimFilts**: (Optional) `false` by default. If `true` then [psychoacoustic optimisation filters](AmbisonicOptimsiation.md) will be applied before decoding the signal. ### AmbisonicAllRAD: Decoding a Signal A B-format signal can be decoded to the loudspeaker signals using the `Process()` function. The processing is non-replacing, so the original B-format signal is unchanged and the decoded signal is contained in the output array. The inputs are: - **pBFSrc**: A pointer to the source B-format signal. - **nSamples**: The length of the input signal in samples. - **ppDst**: Array of pointers of size nLdspk x nSamples containing the decoded signal. ### AmbisonicAllRAD Code Example This example shows how to decode an Ambisonics signal to an ITU 5.1 loudspeaker layout using the AllRAD method. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the decoder for a 5.1 layout AmbisonicAllRAD myDecoder; myDecoder.Configure(nOrder, nBlockLength, sampleRate, "0+5+0"); // Configure buffers to hold the decoded signal const unsigned int nLdspk = myDecoder.GetSpeakerCount(); float** ldspkOut = new float* [nLdspk]; for (int iLdspk = 0; iLdspk < nLdspk; ++iLdspk) ldspkOut[iLdspk] = new float[nBlockLength]; // Decode the Ambisonics signal myDecoder.Process(&myBFormat, nBlockLength, ldspkOut); // Cleanup for (unsigned iLdspk = 0; iLdspk < nLdspk; ++iLdspk) delete[] ldspkOut[iLdspk]; delete[] ldspkOut; ``` ## References [1] Franz Zotter, Hannes Pomberger, and Markus Noisternig. Energy-Preserving Ambisonic Decoding. Acta Acustica united with Acustica, 98(1):37-47, January 2012. doi: . [2] Franz Zotter and Matthias Frank. All-round ambisonic panning and decoding. Journal of the Audio Engineering Society, 60(10):807-820, 2012. [3] MA Poletti. Three-Dimensional Surround Sound Systems Based on Spherical Harmonics. J. Audio Eng. Soc, 53(11):1004-1025, 2005. [4] Franz Zotter and Matthias Frank. Ambisonics: A practical 3D audio theory for recording, studio production, sound reinforcement, and virtual reality. Springer Nature, 2019. [5] Bruce Wiggins. The generation of panning laws for irregular speaker arrays using heuristic methods. In AES 31st International Conference, London, 2007. [6] Michael Gerzon. General metatheory of auditory localisation. In 92nd Convention of the Audio Engineering Society, Vienna, March 1992. [7] Ville Pulkki. Virtual sound source positioning using vector base amplitude panning. J. Audio Eng. Soc 45(6):456-466, 1997. videolan-libspatialaudio-2d42ddf/docs/AmbisonicEncoding.md000066400000000000000000000151171511423056100240020ustar00rootroot00000000000000# Ambisonic Encoding If you are not interested in the theory you can read about how to use `AmbisonicEncoder` [here](#ambisonicencoder). ## Theory and Implementation Details Ambisonic encoding is the conversion of a mono signal to Ambisonics of a specified order. Ambisonic order governs the spatial resolution of the sound scene. Higher orders lead to higher resolution at the expense of increased processing requirements. The number of encoded channels is $`(N + 1)^{2}`$ meaning 1st, 2nd and 3rd order require 4, 9 and 16 channels respectively. A mono input signal is converted to Ambisonics through multiplication with a series of encoding gains. `libspatialaudio`uses the AmbiX specification [[1]](#ref1), which orders the channels in the ACN format and uses SN3D normalisation. AmbiX is currently the most widely used Ambisonics format. The encoded signal is thus calculated as ```math \textbf{b}_{N}(t) = \textbf{y}_{N}(\theta,\phi)s(t) ``` where $`s(t)`$ is the mono input signal at time $`t`$ and $`\textbf{y}_{N}(\theta,\phi)`$ is a column vector of length $`(N + 1)^{2}`$ containing the SN3D-weighted spherical harmonic gains $`[Y_{0}^{0}(\theta, \phi), Y_{1}^{-1}(\theta, \phi), Y_{1}^{0}(\theta, \phi),\ldots,Y_{N}^{N}(\theta, \phi)]^{\mathrm{T}}`$. The angles $`\theta`$ and $`\phi`$ are the direction of the sound source and are expected in degrees. The azimuth $`\theta`$ is positive in the anti-clockwise direction, so +90° is to the left of the listener. The elevation $`\phi`$ ranges from -90° below the listener to +90° above. ### Encoding Gain Interpolation In order to allow to real-time changes in source direction with minimal audio artefacts ("zipper" sounds) as the direction changes, `AmbisonicEncoder` uses an instance of `GainInterp` internally. Every time the direction of the source is changed the gain vector $`\textbf{y}_{N}(\theta,\phi)`$ is updated and a linear interpolation is applied going from the current to new values. This length of the interpolation can be specified by the user. Its ideal length will depend on the signals but 10 ms will reduce most "zipper" sounds. ## AmbisonicEncoder The `AmbisonicEncoder` class is used to convert a mono signal to Ambisonics. When the encoding position is modified it internally smooths the encoding gains $`\textbf{y}_{N}(\theta,\phi)`$ to avoid unwanted clicks in the output. ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: A bool to indicate if the signal is to be encoded to 2D (azimuth only) or 3D (azimuth and elevation). 3D should be preferred. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **fadeTimeMilliSec**: The time in milliseconds to fade from an old set of encoding gains to another. Lower values will lead to lower latency at the expense of possible audio artefacts. Higher values will lead to increased latency before the source reaches the new encoded position. A value of 10 ms is usually a good starting point. ### Set Encoding Direction The encoding direction is set as a polar direction in radians using the `SetPosition()` function. It takes a `PolarPosition` as an input. Note: the distance is ignored. Only the encoding direction is set. ### Encoding a Signal An array of floats can be encoded using either the `Process()` or `ProcessAccumul()` functions. These two functions process the input signal in the same way. The only difference is that `ProcessAccumul()` will add the newly encoded signal to the output with an optional gain, whereas `Process()` will replace the destination signal with the encoded signal. The inputs are: - **pfSrc**: A pointer to the mono input signal. - **nSamples**: The length of the input signal in samples. - **pBFDst**: A pointer to the destination B-format signal. - **nOffset** Optional offset position when writing to the output. When set to zero this will write the signal to the start of `pBFDst`. Any non-zero value will write to the output with a delay of the specified number of samples, leaving any preceding samples unchanged. The offset and input signal length must not be such that the encoded signal would be written beyond the end of `pBFDst` i.e. `nSamples + nOffset <= pfDst->GetSampleCount()`. - (`ProcessAccumul()` only) **fGain**: Optional gain to apply to the output before it is added to the signal in `pBFDst`. ### Code Example This example shows how to convert a mono sine wave to an Ambisonics signal that rotates around the listener from the front and then to the left, back, right and back to the front. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; const int nBlocks = 94; const int nSigSamples = nBlocks * nBlockLength; // Approximately 1 second @ 48 kHz // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; // Set the fade time to the length of one block const float fadeTimeInMilliSec = 1000.f * (float)nBlockLength / (float)sampleRate; std::vector sinewave(nSigSamples); // Fill the vector with a sine wave for (int i = 0; i < nSigSamples; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Destination B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nSigSamples); myBFormat.Reset(); // Set up and configure the Ambisonics encoder AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, fadeTimeInMilliSec); // Set test signal's initial direction in the sound field PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); for (int iBlock = 0; iBlock < nBlocks; ++iBlock) { // Update the encoding position to reach by the end of the block position.azimuth = (float)(iBlock + 1) / (float)nBlocks * 2.f * (float)M_PI; myEncoder.SetPosition(position); // Encode the first block, writing to the appropriate point of the destination buffer const unsigned int iSamp = iBlock * nBlockLength; myEncoder.Process(&sinewave[iSamp], nBlockLength, &myBFormat, iSamp); } ``` ## References [1] Christian Nachbar, Franz Zotter, Etienne Deleflie, and Alois Sontacchi. Ambix - A Suggested Ambisonics Format. In Ambisonics Symposium, volume 3, pages 1-11, Lexington, KY, 2011 videolan-libspatialaudio-2d42ddf/docs/AmbisonicOptimisation.md000066400000000000000000000157551511423056100247430ustar00rootroot00000000000000# Ambisonic Psychoacoustic Optimisation If you are not interested in the theory you can read about how to use `AmbisonicOptimFilters` [here](#ambisonicoptimfilters). ## Theory and Implementation Details When decoding ambisonic signals to loudspeakers (or binaural using the virtual loudspeaker approach) there is a limit frequency $`f_{\mathrm{lim}}`$ above which the sound field is no longer considered well-reproduced. This limit frequency increases with the ambisonic order as can be approximated using [[1]](#ref1) ```math f_{\mathrm{lim}} = \frac{c N}{4 R (N + 1) \sin(\pi/(2N + 2))} ``` where $c$ is the speed of sound in m/s, and $R$ is the radius of the reproduction area in metres. For a central listener, and assuming $R = 0.09$ m (approximate radius of a human head), the limit frequencies for 1st to 3rd order are approximately 674 Hz, 1270 Hz, and 1867 Hz. Ambisonic theory optimises for the velocity vector at low frequencies and the energy vector at higher ones. This optimisation is performed simply by applying a gain by-order to the input signal. At low frequencies the gain is unity and this is known as a basic decoder. At higher frequencies it the gains are chosen to psychoacoustically optimised the signal. This is done such that the energy in the decoded loudspeaker array is concentrated in the source direction. This is known as max $`\textbf{r}_{\textrm{E}}`$ decoding. The weights applied to the channels of each set of channels of degree $n$ are ```math a_{n}^{2D} = \cos\left( \frac{n\pi}{2N + 2} \right) ``` for 2D decoding [[2]](#ref2). For 3D decoding they can be approximated using [[3]](#ref3) ```math a_{n}^{3D} = P_{n}\left(\cos \left(\frac{137.9^{\circ}}{N + 1.51}\right) \right) ``` where $P_{n}$ is a Legendre polynomial. The decoding equation (see [here](AmbisonicDecoding.md)) becomes ```math \textbf{x}(t) = \textbf{D}_{N}^{\mathrm{SN3D}} \mathrm{diag}(\textbf{a}_N)\textbf{b}_{N}(t) ``` where $`\textbf{a}_N`$ is a vector of length $`(N + 1)^{2}`$ containing the max $`r_{\mathrm{E}}`$ gains with an energy compensation gain applied. The gains applied to frequencies below the limit frequency are all unity so $`\mathrm{diag}(\textbf{a}_N)`$ is the identity matrix, meaning the above equation collapses back to the original decoding equation. The frequency-dependent application of these gains leads to a set of shelf filters that are applied to channels of the same order. The filtered signal can then be decoded using a frequency-independent decoder. ### Shelf Filter Implementation Psychoacoustic optimisation is implemented in `AmbisonicOptimFilters`. In order to apply the optimisation gains in a frequency-dependent manner $`\textbf{b}_{N}`$ is filtered by shelf filters with a transition frequency set to the limit frequency, unity gain below and $`a_{n}`$ gain above. The filters must be phase-matched to ensure correct decoding. `AmbisonicOptimFilters` uses 4th-order Linkwitz-Riley filters for this purpose. These are implemented as IIR filters, meaning that the optimisation filtering will have low latency suitable for real-time applications. Linkwitz-Riley filters have the advantageous property that when a low-passed and high-passed signal are summed the magnitude response is flat. In practice, `AmbisonicOptimFilters` applies a low- and high-pass filter to the input, multiplies the low-passed signal by $`a_{n}`$ and sums it with the high-passed signal. The magnitude responses of each of the optimisation filters is shown in the graphs below for orders 1 to 3. ![Graphs showing the loudspeaker gains as a function of source direction for 5.1 and 7.1 layouts from 1st to 3rd order.](images/shelf_filters.png) **Note**: `AmbisonicDecoder` and `AmbisonicAllRAD` already use `AmbisonicOptimFilters` internally. Therefore, psychoacoustic optimisation should not be applied before using these decoders. ## AmbisonicOptimFilters ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: A bool to indicate if the signal is to be filtered is 2D (azimuth only) or 3D (azimuth and elevation). - **nBlockSize**: The maximum number of samples the object is expected to process at a time. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. ### Set Custom Optimisation Gains `AmbisonicOptimFilters` defaults to using max $`r_{E}`$ optimisation. However, the user can supply their own optimisation gains to be applied to the high frequency shelf using `SetHighFrequencyGains()`. The number of gains should be equal to $`N + 1`$. ### Apply Optimisation Filters A B-format signal can be optimised using the `Process()` function. The input signal is replaced by the optimised signal. The inputs are: - **pBFSrcDst**: A pointer to the source B-format signal that is replaced with the processed signal. - **nSamples**: The length of the input signal in samples. ## Example ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; // Set the fade time to the length of one block const float fadeTimeInMilliSec = 1000.f * (float)nBlockLength / (float)sampleRate; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the optimisation filters AmbisonicOptimFilters myOptim; myOptim.Configure(nOrder, true, nBlockLength, sampleRate); // Filter the Ambisonics signal myOptim.Process(&myBFormat, nBlockLength); ``` ## References [1] Stéphanie Bertet, Jérôme Daniel, Etienne Parizet, and Olivier Warusfel. Investigation on localisation accuracy for first and higher order Ambisonics reproduced sound sources. Acta Acustica united with Acustica, 99(4):642–657, 2013. doi: . [2] Jérôme Daniel. Représentation de champs acoustiques, application à la transmission et à la reproduction de scènes sonores complexes dans un contexte multimédia. PhD thesis, University of Paris 6, 2000. [3] Franz Zotter and Matthias Frank. All-round ambisonic panning and decoding. Journal of the Audio Engineering Society, 60(10):807-820, 2012. videolan-libspatialaudio-2d42ddf/docs/AmbisonicRotation.md000066400000000000000000000135561511423056100240600ustar00rootroot00000000000000# Ambisonic Rotation If you are not interested in the theory you can read about how to use `AmbisonicRotator` [here](#ambisonicrotator). ## Theory and Implementation Details Any signal in the ambisonic domain can be rotated by application of a rotation matrix. This allows (for example) head tracking data to be used to rotate the sound field in the opposite direction to how the listener is moving their head, which will keep the sound sources in the correct absolute position in space, rather than them moving with the listeners head. Rotation is performed by multiplying the Ambisonic signal $`\textbf{b}_{N}(t)`$ by a rotation matrix: ```math \textbf{b}'_{N}(t) = \textbf{R}_{N}(\alpha, \beta, \gamma) \textbf{b}_{N}(t). ``` The rotation angles are yaw $`\alpha`$, pitch $`\beta`$ and roll $`\gamma`$ around the z-axis, y-axis and x-axis respectively. A positive yaw angle will cause a sound source to rotated in a clockwise direction with respect to the origin when viewed from along the z-axis (above). From the point-of-view of the listener this is as if they turn to their left. A positive pitch angle will cause a sound source to move above the listener. From the point-of-view of the listener this is as if they tilt their head forward. A positive roll angle will rotate a sound from the left to the right underneath the listener. From the point-of-view of the listener this is as if they roll their head to the right. Rotations can be applied in any order but changing the order of the rotation will not result in the same output, so care must be taken. The yaw-pitch-roll order, where rotations around the z-axis are performed first, is common in Ambisonics, but `AmbisonicRotator` gives the option for any combination to be used. Rotation of the sound field is particularly beneficial when working with a binaural renderer because it fixes the sound sources in space. This can help to reduce front-to-back confusions or with sound source externalisation. Note that `AmbisonicRotator` uses hard-coded equations to generate the individual yaw, pitch and roll rotation matrices. However, for higher orders a recurrence relation based method can be used to compute $`\textbf{R}_{N}(\alpha, \beta, \gamma)`$ [[1]](#ref1). ## AmbisonicRotator The `AmbisonicRotator` class is used to change the orientation of a supplied Ambisonic signal in real-time. In order to avoid clicks while rotating the rotation matrices are interpolated over a specified length of time set during configuration of the object. ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: `AmbisonicRotator` only supports rotation of 3D sound scenes. This should be set to `true` or else configuration will fail. - **nBlockSize**: The maximum block size `Process()` is expected to handle. - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **fadeTimeMilliSec**: The time in milliseconds to fade from an old matrix to another. Lower values will lead to lower latency at the expense of possible audio artefacts. Higher values will lead to increased latency before the source reaches the new orientation. A value of 10 ms is usually a good starting point. ### Set Rotation Order and Orientation The default rotation ordering is yaw-pitch-roll. However any desired order can be specified using `SetRotationOrder()`. Changing the rotation ordering will cause the rotation matrix to be updated using the new ordering. The yaw, pitch and roll values are set by passing a `RotationOrientation` to `SetOrientation()`. The rotation angles should be supplied in radians. ### Rotating an Ambisonic Signal A B-format signal can be rotated using the `Process()` function. The input signal is replaced by the rotated signal. The inputs are: - **pBFSrcDst**: A pointer to the source B-format signal that is replaced with the processed signal. - **nSamples**: The length of the input signal in samples. ### Code Example This example shows how to rotate an Ambisonics signal by 90 degrees ($'\pi/2'$ radians) so that it is heard as coming from the right of the listener when decoded. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; // Set the fade time to the length of one block const float fadeTimeInMilliSec = 1000.f * (float)nBlockLength / (float)sampleRate; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the rotator AmbisonicRotator myRotator; myRotator.Configure(nOrder, true, nBlockLength, sampleRate, fadeTimeInMilliSec); RotationOrientation rotOri; rotOri.yaw = 0.5 * M_PI; // pi/2 radians = 90 degrees myRotator.SetOrientation(rotOri); // Rotate the Ambisonics signal myRotator.Process(&myBFormat, nBlockLength); ``` ## References [1] Joseph Ivanic and Klaus Ruedenberg. Rotation matrices for real spherical harmonics. direct determination by recursion. The Journal of Physical Chemistry, 100(15):6342-6347, 1996. videolan-libspatialaudio-2d42ddf/docs/AmbisonicZoomer.md000066400000000000000000000073401511423056100235260ustar00rootroot00000000000000# Ambisonic Zoomer If you are not interested in the theory you can read about how to use `AmbisonicZoomer` [here](#ambisoniczoomer). ## Theory and Implementation Details The `AmbisonicZoomer` class allows for a kind of acoustic zoom to the front of the sound field. It was implemented for use with the zoom function with 360-videos in VLC Media Player to place emphasis on sounds in the view direction. It samples the sound field to the front with a virtual cardioid microphone with order matching the order of the input signal. This mono virtual microphone signal is then re-encoded back to a signal at the front of the sound field and blended with the full sound field based on the zoom value set in `AmbisonicZoomer::SetZoom`. A zoom value of 0 will perform no transformation to the ambisonic signal while a zoom of 1 will lead to an extreme zoom, which results in mono signal encoded to the front of the sound field. Another method for achieving a similar effect would be to decode the Ambisonics signal to a set of points regularly spaced on the sphere, applying a directional weight to these points, then re-encoding the points to Ambisonics. However, this requires a transformation from and to the Ambisonics domain over a large number of points. This makes it more CPU intensive than the simple method used here, and so it is not implemented in `libspatialaudio`. ## AmbisonicZoomer ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **nOrder**: The ambisonic order from 1 to 3. - **b3D**: A bool to indicate if the signal is to be decoded is 2D (azimuth only) or 3D (azimuth and elevation). - **nBlockSize**: The maximum block size `Process()` is expected to handle. - **sampleRate**: The sample rate of the signal expected by `Process()`. ### Setting the Zoom Amount The amount of zoom can be set from 0 to 1 using 'SetZoom()'. A value of 0 corresponds to no zoom and the signal will be returned unchanged after processing. A value of 1 means that the maximum amount of zooming will be applied and almost all of the signal will be from the re-encoded forward-facing virtual microphone. ### Zooming a Signal A B-format signal can have zooming applied using the `Process()` function. The input signal is replaced by the processed signal. The inputs are: - **pBFSrcDst**: A pointer to the source B-format signal. - **nSamples**: The number of samples to process. ### Code Example This example shows how to apply zooming to an Ambisonics signal. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Set up the zoomer processor AmbisonicZoomer myZoomer; myZoomer.Configure(nOrder, true, nBlockLength, 0); myZoomer.SetZoom(0.5f); // Apply zooming to the Ambisonics signal myZoomer.Process(&myBFormat, nBlockLength); ``` videolan-libspatialaudio-2d42ddf/docs/AmbisonicsOverview.md000066400000000000000000000133021511423056100242370ustar00rootroot00000000000000# Ambisonic Processing Overview If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Ambisonic Processors The main Ambisonic processing classes are: - `AmbisonicEncoder`: Converts a mono signal to an Ambisonics signal of order 1 to 3. - Read more [here](AmbisonicEncoding.md). - Go directly to the coding details [here](AmbisonicEncoding.md#ambisonicencoder). - `AmbisonicRotator`: Applies a user-specified rotation to the sound field. This is useful for head tracking or keeping the audio aligned with a 360 video. - Read more [here](AmbisonicRotation.md). - Go directly to the coding details [here](AmbisonicRotation.md#ambisonicrotator). - `AmbisonicZoomer`: An acoustical "zoom" that focuses on the front of the sound scene. - Read more [here](AmbisonicZoomer.md). - Go directly to the coding details [here](AmbisonicZoomer.md#ambisoniczoomer). - `AmbisonicDecoder`: A decoder that converts an Ambisonics signal to a set of loudspeaker signals. It contains optimised presets for 5.1 and 7.1 loudspeaker layouts. Custom layouts can also have their decoding matrix defined by the user, for additional flexibility. - Read more [here](AmbisonicDecoding.md). - Go directly to the coding details [here](AmbisonicDecoding.md#ambisonicdecoder). - `AmbisonicBinauralizer`: A decoder that converts an Ambisonics signal to a binaural signal. This allows for immersive audio to be experienced over headphones. Custom HRTFs can be loaded using the .SOFA format, allowing for a customised listening experience. - Read more [here](AmbisonicBinauralization.md). - Go directly to the coding details [here](AmbisonicBinauralization.md#ambisonicbinauralizer) - `AmbisonicAllRAD`: A decoder that converts an Ambisonics signal to a set of loudspeaker signals corresponding to the ITU layouts or IAMF specificiation layouts. It uses the AllRAD method to calculate the decoding matrix. - Read more [here](AmbisonicDecoding.md). - Go directly to the coding details [here](AmbisonicDecoding.md#ambisonicallrad) ## Ambisonics Signal Flow In general, unless your signal is already in Ambisonics format, the signal chain will begin with `AmbisonicEncoder` to bring the audio in to the Ambisonics domain. The rotation and zooming processing elements are optional and will be context dependent. However, they should generally be applied to a summation of all the sound sources making up the scene, rather than applying to each one individually. Finally, the signal needs to be converted from a Ambisonics to the listener's particular layout. The choice of which decoder should be used is generally decided by the target output layout. ITU layouts could use `AmbisonicAllRAD` or, if a custom decoder is available, `AmbisonicDecoder`. Binauralisation over headphones uses `AmbisonicBinauralization`. ![Graph showing the signal flow to encode a mono signal to HOA, adding to any pre-encoded HOA streams, with rotation and zooming processing before decoding to different formats.](images/AmbisonicSignalFlow.png) The above figure shows the signal flow used to encode a mono input signal to HOA, perform rotation of the sound field (using `AmbisonicRotator`) and then to acoustically zoom on the front of the sound field (using `AmbisonicZoomer`). Finally, it is decoded to the listener using one of the decoding methods. ## Code Example This example shows how to apply the entire signal chain described above and to convert the output to binaural. See [here](AmbisonicDecoding.md) for specific examples on how to decode using `AmbisonicDecoder` or `AmbisonicAllRAD`. ```c++ #include "Ambisonics.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; // Set the fade time to the length of one block const float fadeTimeInMilliSec = 1000.f * (float)nBlockLength / (float)sampleRate; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Encode the signal to Ambisonics AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, 0); PolarPosition position; position.azimuth = 0; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); // Set up the rotator AmbisonicRotator myRotator; myRotator.Configure(nOrder, true, nBlockLength, sampleRate, fadeTimeInMilliSec); RotationOrientation rotOri; rotOri.yaw = 0.5 * M_PI; myRotator.SetOrientation(rotOri); // Set up the zoomer processor AmbisonicZoomer myZoomer; myZoomer.Configure(nOrder, true, nBlockLength, 0); myZoomer.SetZoom(0.5f); // Set up the binaural decoder AmbisonicBinauralizer myDecoder; unsigned int tailLength = 0; myDecoder.Configure(nOrder, true, sampleRate, nBlockLength, tailLength); // Configure buffers to hold the decoded signal const unsigned int nEar = 2; float** earOut = new float* [nEar]; for (int iEar = 0; iEar < nEar; ++iEar) earOut[iEar] = new float[nBlockLength]; // Process the audio ============================== // Encode the signal to Ambisonics myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Rotate the Ambisonics signal myRotator.Process(&myBFormat, nBlockLength); // Apply zooming to the Ambisonics signal myZoomer.Process(&myBFormat, nBlockLength); // Decode the signal to binaural myDecoder.Process(&myBFormat, earOut, nBlockLength); // Cleanup for (unsigned iEar = 0; iEar < nEar; ++iEar) delete[] earOut[iEar]; delete[] earOut; ``` videolan-libspatialaudio-2d42ddf/docs/LoudspeakerBinauralization.md000066400000000000000000000106241511423056100257570ustar00rootroot00000000000000# Loudspeaker Binauralization If you are not interested in the theory you can read about how to use `SpeakerBinauralization` [here](#speakersbinauralizer). ## Theory and Implementation Details Binauralization of a loudspeaker array uses a simple method. First, a pair of head-related impulse responses (HRIRs) for each of the loudspeaker directions is convolved with the signal of that loudspeaker. The convolved signals are summed to give a final 2-channel binaural signal for listening over headphones. ```math z_{ear}(t) = \sum_{m = 0}^{M - 1} h_{m,ear}(t)\circledast x_{m}(t) ``` where $`z_{ear}(t)`$ is the signal at the left or right ear, $`h_{ear}`$ is the corresponding HRIR for the left/right ear, $`x_{m}(t)`$ is the signal of the $m$-th loudspeaker and $M$ is the total number of loudspeakers. `SpeakersBinauralizer` provides a simple convolution of a set of supplied loudspeaker signals with a pair of HRTFs (one for each ear). The convolution is implemented in the frequency domain using an overlap-add algorithm. If `libmysofa` is activated at compile time then the HRTF can be loaded from a .SOFA file, allowing for the use of custom HRTFs. Custom HRTFs allow for users to potentially load their own HRTF, giving highly personalised rendering. ## SpeakersBinauralizer ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **sampleRate**: The sample rate of the audio being used e.g. 44100 Hz, 48000 Hz etc. This must be an integer value greater than zero. - **nBlockSize**: The maximum number of samples the decoder is expected to process at a time. - **speakers**: A pointer to an array of `AmbisonicSpeaker` holding the speaker directions. - **nSpeakers**: The number of speakers to be binauralized. - **tailLength**: The value is replaced with the length of the HRIRs used for the binauralisation. - **HRTFPath**: An optional path to the .SOFA file containing the HRTF. If no path is supplied and the `HAVE_MIT_HRTF` compiler flag is used then the MIT HRTF will be used. ### Binauralizing a Signal A set of loudspeaker signals can be decoded to the binaural signals using the `Process()` function. The processing is non-replacing, so the original loudspeaker signals are unchanged and the decoded signal is contained in the output array. The inputs are: - **pBFSrc**: A pointer to the source B-format signal. - **ppDst**: Array of pointers of size 2 x nBlockSize containing the binaurally decoded signal. ### Code Example This example shows how to convert a set of loudspeaker signals to a 2-channel binaural signal. ```c++ #include "SpeakersBinauralizer.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Configure the speaker layout const unsigned int nSpeakers = 5; AmbisonicSpeaker speakers[nSpeakers]; speakers[0].SetPosition({ 30.f / 180.f * (float)M_PI, 0.f, 1.f }); // L speakers[1].SetPosition({ -30.f / 180.f * (float)M_PI, 0.f, 1.f }); // R speakers[2].SetPosition({ 0.f / 180.f * (float)M_PI, 0.f, 1.f }); // C speakers[3].SetPosition({ 110.f / 180.f * (float)M_PI, 0.f, 1.f }); // Ls speakers[4].SetPosition({ -110.f / 180.f * (float)M_PI, 0.f, 1.f }); // Rs // Configure buffers to hold the 5.0 signal float** ldspkInput = new float* [5]; for (int iLdspk = 0; iLdspk < 5; ++iLdspk) { ldspkInput[iLdspk] = new float[nBlockLength]; // Fill L and C channels, panning the signal to half way between both speakers for (int i = 0; i < nBlockLength; ++i) ldspkInput[iLdspk][i] = iLdspk == 0 || iLdspk == 2 ? (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate) : 0.f; } // Set up the binauralizer SpeakersBinauralizer myBinaural; unsigned int tailLength = 0; myBinaural.Configure(sampleRate, nBlockLength, speakers, nSpeakers, tailLength); // Configure buffers to hold the decoded signal const unsigned int nEar = 2; float** earOut = new float* [nEar]; for (int iEar = 0; iEar < nEar; ++iEar) earOut[iEar] = new float[nBlockLength]; // Convert the loudspeaker signals to binaural myBinaural.Process(&ldspkInput[0], earOut); // Cleanup for (unsigned iEar = 0; iEar < nEar; ++iEar) delete[] earOut[iEar]; delete[] earOut; for (unsigned iLdspk = 0; iLdspk < nSpeakers; ++iLdspk) delete[] ldspkInput[iLdspk]; delete[] ldspkInput; ``` videolan-libspatialaudio-2d42ddf/docs/ObjectPanning.md000066400000000000000000000125031511423056100231440ustar00rootroot00000000000000# Object Panning If you are not interested in the theory you can read about how to use `ObjectPanner` [here](#objectpanner). ## Theory and Implementation Details Object-based panning is the process of placing a mono signal at an arbitrary position in a loudspeaker layout by distributing its energy across the available loudspeakers. `ObjectPanner` implements Vector Base Amplitude Panning (VBAP) following the algorithm described in the Audio Definition Model (ADM) renderer specification [[1](#ref1), [2](#ref2)]. `ObjectPanner` can be used to pan a mono sound source as a point source on a given loudspeaker array. More advanced Object rendering is possible with the `Renderer` class that allows for metadata to specify additional parameters, such as object extent. ### VBAP Algorithm Classic VBAP works by selecting a subset of loudspeakers (a base) that encloses the desired source direction and calculating gain factors such that the vector sum of the loudspeaker positions matches the target direction. The gains are normalized to preserve energy. For a source at direction vector $`\mathbf{d}`$ and a loudspeaker base matrix $`\mathbf{L}`$ containing unit vectors in the loudspeaker directions, the gains $`\mathbf{g}`$ are obtained by solving: ```math \mathbf{L} \mathbf{g} = \mathbf{d} ``` with the constraint that all elements of g are non-negative. The resulting gains $`g'`$ are then normalized: ```math \mathbf{g}' = \frac{\mathbf{g}}{\|\mathbf{g}\|} ``` ### Gain Interpolation To avoid audible artefacts when the source position changes (clicks or "zipper noise"), `ObjectPanner` uses an internal `GainInterp` object. When the position is updated, the loudspeaker gain vector is interpolated over a user-specified fade time (typically 10 ms). This ensures smooth transitions. ## ObjectPanner The `ObjectPanner` class is used to distribute a mono signal across a loudspeaker layout using VBAP. It supports smooth position updates to reduce real-time "zipper" effects for moving sources. ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then it will return `true` and the object can now be used. The configuration parameters are: - **layout**: An `OutputLayout` to select a support output layout. - **sampleRate**: The sample rate of the audio being used (e.g. 44100 Hz, 48000 Hz). Must be an integer > 0. - **fadeTimeMilliSec**: The time in milliseconds to fade from an old set of panning gains to another. Lower values reduce latency but may introduce artefacts; higher values increase smoothness at the cost of responsiveness. ### Set Panning Position The panning position is set as a polar direction in radians using the `SetPosition()` function. It takes a `PolarPosition` as input. ### Panning a Signal An array of floats can be panned using either the `Process()` or `ProcessAccumul()` functions. These two functions process the input signal in the same way. The only difference is that `ProcessAccumul()` will add the newly panned signal to the output with an optional gain, whereas `Process()` will replace the destination signal with the panned signal. The inputs are: - **pfSrc**: A pointer to the mono input signal. - **nSamples**: The length of the input signal in samples. - **ppDst**: A pointer to the destination buffer containing one channel per loudspeaker. - **nSamplesOut**: The number of samples in the output buffer. Must be at least `nSamplesIn` + `nOffset` in value. - **nOffset**: Optional offset position when writing to the output. - (`ProcessAccumul()` only) **fGain**: Optional gain to apply before accumulation. --- ### Code Example This example shows how to pan a mono sine wave into a 5.1 loudspeaker layout using `ObjectPanner`. ```c++ #include "ObjectPanner.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; auto layout = OutputLayout::FivePointOne; ObjectPanner objPanner; objPanner.Configure(layout, sampleRate, 1000.f * (float)nBlockLength / (float)sampleRate); unsigned nLdspk = (unsigned)objPanner.GetNumSpeakers(); // Generate a block of sine wave samples std::vector sinewave(nBlockLength); for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Prepare the output stream (5.1 layout) float** renderStream = new float* [nLdspk]; for (unsigned int i = 0; i < nLdspk; ++i) { renderStream[i] = new float[nBlockLength]; std::fill(renderStream[i], renderStream[i] + nBlockLength, 0.f); } for (float az = 0.f; az < 360.f; az += 1.f) { auto position = PolarPosition{ az, 0.f, 1.f }; objPanner.SetPosition(position); objPanner.Process(sinewave.data(), nBlockLength, renderStream, nBlockLength); } for (unsigned iLdspk = 0; iLdspk < nLdspk; ++iLdspk) delete[] renderStream[iLdspk]; delete[] renderStream; ``` ## References [1] Ville Pulkki. Virtual sound source positioning using vector base amplitude panning. J. Audio Eng. Soc 45(6):456-466, 1997. [2] International Telecommunication Union. Audio Definition Model renderer for advanced sound systems. International Telecommunication Union, Geneva, Switzerland, Recommendation ITU-R BS.2127-1 edition, 2023. URL . videolan-libspatialaudio-2d42ddf/docs/RendererAmbisonics.md000066400000000000000000000111421511423056100241770ustar00rootroot00000000000000# Rendering Ambisonics Using The `Renderer` Class If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Introduction `Renderer` allows for Higher Order Ambisonics (HOA) streams to be decoded to any of the specified loudspeaker layouts (see [here](RendererOverview.md#supported-output-formats)). It supports decoding up to a maximum of order 3. Decoding is performed using the AllRAD method, using the`AmbisonicAllRAD` class internally. See [here](AmbisonicDecoding.md#cambisonicallrad) for more details about the AllRAD method. The HOA stream has the "order" and "degree" of each channel defined in its metadata which is used to sort the channels of the stream. This allows `Renderer` to use arbitrary channel orderings. `Renderer` uses the ACN channel sorting internally. The normalisation of the orders can be SN3D, N3D or FuMa. The signals are converted to SN3D, if they are not already. Converting to ACN channel sorting and SN3D normalisation ensures the signal is in the AmbiX format, ensuring the signals are compatible with the `libspatialaudio` Ambisonics processors. Full details can be found in section 9 of Rec. ITU-R BS.2127-1. ## Code Example In this example an HOA signal is decoded to binaural. The AmbiX (SN3D/ACN) HOA stream and its metadata are generated as part of the example but would normally be received from the stream to be rendered. The HOA stream is then added to the renderer using `AddHOA()`, which adds it to an internal buffer. `AddHOA()` can be called multiple times if there are multiple HOA streams to be rendered. When `GetRenderedAudio()` is called the accumulated HOA buffer is decoded to the specified output format. The internal HOA buffer is then cleared so that new streams can be added to the next frame to be rendered. For a more complete example with multiple different stream types being rendered see [here](RendererOverview.md#code-example). ```c++ #include "Renderer.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Higher ambisonic order means higher spatial resolution and more channels required const unsigned int nOrder = 1; const unsigned int nHoaCh = OrderToComponents(nOrder, true); // Set the fade time to the length of one block const float fadeTimeInMilliSec = 1000.f * (float)nBlockLength / (float)sampleRate; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Destination B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nBlockLength); myBFormat.Reset(); // Set up and configure the Ambisonics encoder AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, fadeTimeInMilliSec); // Set test signal's initial direction in the sound field PolarPosition position; position.azimuth = 0.5f * (float)M_PI; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(sinewave.data(), nBlockLength, &myBFormat); // Prepare the stream to be processed by the renderer float** hoaStream = new float* [nHoaCh]; for (unsigned int i = 0; i < nHoaCh; ++i) { hoaStream[i] = new float[nBlockLength]; myBFormat.ExtractStream(hoaStream[i], i, nBlockLength); } // Prepare the stream to hold the rendered audio (binaural) float** renderStream = new float* [2]; for (unsigned int i = 0; i < 2; ++i) { renderStream[i] = new float[nBlockLength]; } // Prepare the metadata for the stream HoaMetadata hoaMetadata; hoaMetadata.normalization = "SN3D"; // Configure the stream information. In this case there is only a single HOA stream of (nOrder + 1)^2 channels StreamInformation streamInfo; for (unsigned int i = 0; i < nHoaCh; ++i) { streamInfo.nChannels++; streamInfo.typeDefinition.push_back(TypeDefinition::HOA); // Set the metadata for each channel int order, degree; ComponentToOrderAndDegree(i, true, order, degree); hoaMetadata.degrees.push_back(degree); hoaMetadata.orders.push_back(order); hoaMetadata.trackInds.push_back(i); } // Set up the Renderer Renderer renderer; renderer.Configure(OutputLayout::Binaural, nOrder, sampleRate, nBlockLength, streamInfo); // Add the HOA stream to be rendered renderer.AddHoa(hoaStream, nBlockLength, hoaMetadata); // Render the stream renderer.GetRenderedAudio(renderStream, nBlockLength); // Cleanup for (unsigned i = 0; i < nHoaCh; ++i) delete[] hoaStream[i]; delete[] hoaStream; for (unsigned i = 0; i < 2; ++i) delete[] renderStream[i]; delete[] renderStream; ``` videolan-libspatialaudio-2d42ddf/docs/RendererBinaural.md000066400000000000000000000056531511423056100236570ustar00rootroot00000000000000# Rendering To Binaural Using The `Renderer` Class If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Introduction The ADM specification does not have a specific implementation for rendering to binaural. EBU's BEAR [[1]](#ref1) provides a method for rendering an ADM stream to binaural. However, BEAR requires a binaural room impulse responses (BRIRs) that would increase the size of `libspatialaudio` by too large a degree. Therefore, the binaural rendering of `Renderer` is inspired by BEAR in its use of a virtual loudspeaker layout but the final binauralisation is performed differently, in order to remove the requirement for including more HRTFs than those used for `AmbisonicBinaurlization`. BEAR uses a virtual 9+10+5 loudspeaker layout and then binauralises the loudspeaker signals using BRIRs in the corresponding directions based on the loudspeaker position and the listener head orientation. `Renderer` uses the same virtual loudspeaker layout for rendering Object and DirectSpeaker signals. These loudspeaker signals are then converted to Ambisonics by encoding them based on the loudspeaker directions (ignoring listener head rotation). This encoded signal is then summed with any HOA streams that have been added. The composite stream is then rotated using `AmbisonicRotator` to apply the listener head rotation. Finally, any direct binaural signal are added to the output. The signal flow is shown in the figure below. ![Image showing the signal flow of the ADM binaural renderer in libspatialaudio](images/AdmBinauralSignalFlow.png) ### Advantages and Disadvantages Compared to BEAR The advantages of this method, besides the fact that no new HRTFs need to be added to the library, are that: - the number of expensive convolution is kept low. BEAR needs 48 convolutions (24 loudspeakers, 2 ears) to be performed, compared to 32 using the described method (16 channels, 2 ear). Furthermore, since BEAR uses BRIR the CPU load of the convolutions is increased compared to using anechoic HRIRs. - custom HRTFs can be easily loaded using the .SOFA file format. - in case very low CPU use is required the binaural rendering can use 1st order Ambisonics internally, reducing the number of convolutions to only 8 (or 4 if the symmetric head assumption is used). The main disadvantage of this method is that the lack of the room in rendered binaural could reduce externalisation when compared to the BRIR method. It has been shown that using a BRIR instead of an anechoic HRIR can improve externalisation. ## Code Example See the main [Renderer overview](RendererOverview.md#code-example) for a full code example that renderers multiple different stream types to binaural. ## References [1] European Broadcasting Union. EBU Tech 3369: Binaral EBU ADM Renderer (BEAR) for Object-Based Sound Over Headphones, Geneva, Switzerland, 2023. URL . videolan-libspatialaudio-2d42ddf/docs/RendererDirectSpeaker.md000066400000000000000000000062021511423056100246360ustar00rootroot00000000000000# DirectSpeaker Rendering Using The `Renderer` Class If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Introduction A mono audio stream with DirectSpeaker metadata is spatialised by sending it directly to the specified loudspeaker i.e. a DirectSpeaker stream labelled as belonging to the left loudspeaker will be sent to it directly. If the specified loudspeaker is not present in the reproduction layout then it checks a set of MappingRules. In the case a suitable mapping rule exists, it will be used to calculate the gains to be applied to the stream. As a fallback, or if no label is supplied, the position of the DirectSpeaker stream can be specified. After screen edge locking, the position of the stream is checked and if there is a sufficiently close loudspeaker then the signal will be sent directly to it. If no loudspeaker is close enough then the DirectSpeaker stream is panned as a point source to its specified direction. Full details can be found in section 8 of Rec. ITU-R BS.2127-1. ## Code Example In this example a DirectSpeaker signal for the wide-left (M+060) loudspeaker from a 9+10+3 layout is rendered to a 5.1 layout. The stream and its metadata are generated as part of the example but would normally be received from the stream to be rendered. The stream is first added to be rendered using `AddDirectSpeaker()`. When `GetRenderedAudio()` is called the stream is converted (in this case) to binaural and the DirectSpeaker buffer internally is cleared, ready for the next `AddDirectSpeaker()` call. ```c++ #include "Renderer.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Ambisonic order (not used in this example but expected in Configure()) const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Prepare the stream to hold the rendered audio (5.1) const unsigned int nLdspk = 6; float** renderStream = new float* [nLdspk]; for (unsigned int i = 0; i < nLdspk; ++i) { renderStream[i] = new float[nBlockLength]; } // Prepare the metadata for the stream DirectSpeakerMetadata directSpeakerMetadata; directSpeakerMetadata.trackInd = 0; directSpeakerMetadata.speakerLabel = "M+060"; // Wide-left speaker directSpeakerMetadata.audioPackFormatID = std::string("AP_00010009"); // 9+10+3 layout // Configure the stream information. In this case there is only a single channel stream StreamInformation streamInfo; streamInfo.nChannels = 1; streamInfo.typeDefinition.push_back(TypeDefinition::DirectSpeakers); // Set up the Renderer Renderer renderer; renderer.Configure(OutputLayout::FivePointOne, nOrder, sampleRate, nBlockLength, streamInfo); // Add the DirectSpeaker stream to be rendered renderer.AddDirectSpeaker(sinewave.data(), nBlockLength, directSpeakerMetadata); // Render the stream renderer.GetRenderedAudio(renderStream, nBlockLength); // Cleanup for (unsigned i = 0; i < nLdspk; ++i) delete[] renderStream[i]; delete[] renderStream; ``` videolan-libspatialaudio-2d42ddf/docs/RendererObject.md000066400000000000000000000216011511423056100233170ustar00rootroot00000000000000# Object Rendering Using The `Renderer` Class If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Introduction When rendering an Object a set of loudspeaker gains are calculated that will pan the object to the direction specified by the metadata. The metadata controls properties such as the width of the sound source, as well as whether or not its position is to be modified based on the reproduction system. The ratio of direct to diffuse signal is also specified in the metadata. The Object direct and diffuse panning gains are computed by `GainCalculator`. Depending on whether the metadata Cartesian flag is true or false the gains will be calculated in one of two ways, described in the following sections. ### Polar Processing Path When the Cartesian flag is set to false the polar processing path is used to render the stream. The figure below shows the processing logic for the calculation of the direct and diffuse gains in `GainCalculator`. ![Figure showing the processing logic for calculating direct and diffuse gains for the Polar path.](images/ObjectPannerSignalFlow.png) The first processing stage relates to whether or not the position of the Object is to be modified. If a reproduction screen has been specified then the Object metadata can request the position of the Object be modified based on the screen properties, potentially modifying the position of the Object. Following that, it is also possible to ensure that the object is sent only to a single loudspeaker, if one is close enough. This is known as Channel Locking. If no loudspeaker is within range then the Object stream is panned using its position. Once the position of the Object has been determined, ObjectDivergence can be applied. If the metadata specifies that Divergence be used then two additional positions are added to the Object position. These positions are to the left and right of the Object position and their distance is specified in the metadata. Each of these positions also has a specified gain based on the amount of divergence. For zero divergence the original Object direction has a gain of unity and the others have zero gain. For full divergence the original Object direction has zero gain and the left and right positions have gains of 0.5. Once the divergence processing is complete the up-to-three divergence positions are each used to calculate a corresponding vector of panning gains based on their positions. The gains are calculated using `SpreadPanner`, which allows for an azimuthal width and elevational height to be specified in the metadata. The spread panner essentially pans copies of the Object to a set of grid positions that cover the full sphere. A weight between 0 and 1 is applied to each of these grid positions based on the metadata width and height parameters before normalisation of the total weight by the sum of the grid weights. The larger the width and height of the specified spread, the more of the grid points have non-zero gains, leading to a larger source width. Each grid point then has panning gains calculated using vector base amplitude panning (VBAP) [[1]](#ref1) based on their position. These gains are multiplied by their corresponding weights and summed to get the final panning gains for each of the three divergence positions. Each of these three vectors of gains are summed using the divergence gains and they are power-normalised. If ZoneExclusion is specified in the metadata then any loudspeaker in the excluded zone will have their gains shared out among other groups of loudspeakers. The full method for calculating the downmixing matrix is given in section 7.3.12.2 of [[2]](#ref2). A global gain is applied to the spatialisation gains before calculation of direct and diffuse gain vectors. The direct and diffuse gain vectors are generated by multiplying the spatialisation gains by $`\sqrt{1-d}`$ and $`\sqrt{d}`$ respectively, where $`d`$ is the diffuseness parameter specified in the metadata. The Object signal is then multiplied by the direct and diffuse gain vectors. The diffuse signal has a set of decorrelation filters of length $N$ applied to each channel, creating a less well localisable signal. After appropriate compensation delay of $`(N-1)/2`$ samples is applied to the direct signal the direct and diffuse signals are summed. ### Cartesian Processing Path If the Cartesian flag is set to true then the cartesian processing path is used to render the stream. The figure below shows the processing logic for the calculation of the direct and diffuse gains in `GainCalculator`. ![Figure showing the processing logic for calculating direct and diffuse gains for the Cartesian path.](images/ObjectPannerSignalFlowCartesian.png) First the zone exclusion metadata is used to create a vector of masks for the loudspeakers in the reproduction layout. These are used when calculating channel locking and extent panning later in the path. Like the Polar path, the position of the Object is modified using screen scaling, screen edge lock and channel locking. The channel mask from the zone exclusion is used to ensure that the object is not locked to a channel that has been excluded. Once the position of the Object has been modified ObjectDivergence is applied. This can create additional copies of the object panned to the left and right of its position. For each of the divergence positions a set of loudspeaker gains is calculated using the `AllocentricExtent`, which uses the height, width and depth metadata parameters. The panning uses the Cartesian/Allocentric panner rather than the PointSourcePanner of the Polar path. These gain vectors are multiplied by their corresponding divergence gains and summed to get the final panning gains for the Object. They are then power normalised and a gain is applied based on the metadata parameter. Finally, the direct and diffuse gains are calculated in the same manner as for the Polar path. ## Code Example This example simulated receiving a mono Object stream and its meta data. As written here, the object is rendered on a 5.1 layout at an angle of 20°. Try adjusting the channel locking, divergence and width to see the effect on the rendering. For example, increasing the channel lock distance will cause the signal to snap to the left speaker completely. ```c++ #include "Renderer.h" using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; // Ambisonic order (not used in this example but expected in Configure()) const unsigned int nOrder = 1; std::vector sinewave(nBlockLength); // Fill the vector with a sine wave for (int i = 0; i < nBlockLength; ++i) sinewave[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Prepare the stream to hold the rendered audio (5.1) const unsigned int nLdspk = 6; float** renderStream = new float* [nLdspk]; for (unsigned int i = 0; i < nLdspk; ++i) { renderStream[i] = new float[nBlockLength]; } // Prepare the metadata for the stream ObjectMetadata objectMetadata; objectMetadata.trackInd = 0; objectMetadata.blockLength = nBlockLength; objectMetadata.cartesian = false; objectMetadata.position.polarPosition().azimuth = 20.; objectMetadata.position.polarPosition().elevation = 0.; objectMetadata.position.polarPosition().distance = 1.; // Channel lock (off by default) objectMetadata.channelLock = ChannelLock(); objectMetadata.channelLock->maxDistance = 0.f; // <- Increase this to see the signal snap to fully in the left loudspeaker // Object divergence (off by default) objectMetadata.objectDivergence = ObjectDivergence(); objectMetadata.objectDivergence->azimuthRange = 30.; // <- Controls the width of the divergence objectMetadata.objectDivergence->value = 0.; // <- Increase this to apply object divergence // Object extent (off by default) objectMetadata.width = 0.; // <- Increase this to increase the width and spread the Object over more adjacent loudspeakers // Configure the stream information. In this case there is only a single channel stream StreamInformation streamInfo; streamInfo.nChannels = 1; streamInfo.typeDefinition.push_back(TypeDefinition::Objects); // Set up the Renderer Renderer renderer; renderer.Configure(OutputLayout::FivePointOne, nOrder, sampleRate, nBlockLength, streamInfo); // Add the Object stream to be rendered renderer.AddObject(sinewave.data(), nBlockLength, objectMetadata); // Render the stream renderer.GetRenderedAudio(renderStream, nBlockLength); // Cleanup for (unsigned i = 0; i < nLdspk; ++i) delete[] renderStream[i]; delete[] renderStream; ``` ## References [1] Ville Pulkki. Virtual sound source positioning using vector base amplitude panning. J. Audio Eng. Soc 45(6):456-466, 1997. [2] International Telecommunication Union. Audio Definition Model renderer for advanced sound systems. International Telecommunication Union, Geneva, Switzerland, Recommendation ITU-R BS.2127-1 edition, 2023. URL . videolan-libspatialaudio-2d42ddf/docs/RendererOverview.md000066400000000000000000000355611511423056100237310ustar00rootroot00000000000000# `Renderer` Class Overview If you are not interested in the details and just want to get coding, see the [code example](#code-example). ## Overview `libspatialaudio` includes a renderer for the Audio Definition Model (ADM) renderer detailed in Rec. ITU-R BS.2127-1 [[1]](#ref1). It also aims to support elements of the AOM's Immersive Audio Model and Formats (IAMF) specification [[2]](#ref2). The ADM standard specifies rendering methods for Objects, HOA, and DirectSpeaker streams: - Object streams consist of a mono audio signal and metadata which specify how they are spatialised. More details can be read [here](RendererObject.md). - HOA streams are summed and decoded to the target playback format (loudspeakers or binaural). More details and an example can be found [here](RendererAmbisonics.md). - DirectSpeaker streams are intended to be sent directly to a specific loudspeaker in the target layout, if it is present. If it is not present then the DirectSpeaker stream will be spatialised based on the target layout and its associated metadata. More details can be read [here](RendererDirectSpeaker.md). Rec. ITU-R BS.2127-1 [[1]](#ref1) should be consulted for full details about the rendering algorithms. ### Supported Output Formats 'Renderer' supports all of the loudspeaker layouts specified in [[1]](#ref1) as well as additional ones specified in the IAMF. The supported ITU layouts are: - `"0+2+0"`: BS.2051-3 System A (Stereo) - `"0+5+0"`: BS.2051-3 System B (5.1) - `"2+5+0"`: BS.2051-3 System C (5.1.2) - `"4+5+0"`: BS.2051-3 System D (5.1.4) - `"4+5+1"`: BS.2051-3 System E - `"3+7+0"`: BS.2051-3 System F - `"4+9+0"`: BS.2051-3 System G - `"9+10+3"`: BS.2051-3 System H - `"0+7+0"`: BS.2051-3 System I (7.1) - `"4+7+0"`: BS.2051-3 System J (7.1.4) The additional IAMF layouts are: - `"2+7+0"`: 7.1.2 (IAMF v1.1.0) - `"2+3+0"`: 3.1.2 (IAMF v1.1.0) A quad layout is also supported, along with the virtual layout specified in [[3]](#ref3): - `"0+4+0"`: Quad - `"9+10+5"`: EBU Tech 3369 (BEAR) 9+10+5 - 9+10+3 with LFE1 & LFE2 removed and B+135 & B-135 added. This is used internally for the binaural rendering. In addition to these loudspeaker layouts, `Renderer` implements a custom binaural renderer that is inspired by the BEAR renderer specified in [[3]](#ref3). Full details on the binaural rendering processing can be read [here](RendererBinaural.md). ## Renderer The `Renderer` is the only class you will need to interact with to render an a mixture of Object, DirectSpeaker and/or HOA feeds, such as ADM or IAMF. It accepts audio streams and metadata to produce a signal rendered to the specified output format. Use the class as follows: 1. Configure the class by informing it of the different streams it should expect. 2. Add each stream using the appropriate function i.e. `AddHOA()` for an Ambisonics signal. 3. Once all streams have been added use `GetRenderedAudio()`. This clears any internal buffers containing waiting audio. 4. Repeat steps 2 and 3. ### Configuration Before calling any other functions the object must first be configured by calling `Configure()` with the appropriate values. If the values are supported then the it will return `true` and the object can now be used. The configuration parameters are: - **outputTarget**: The target output layout selected from `OutputLayout`. - **hoaOrder**: The ambisonic order of the signal to be rendered. This also control the order of the HOA processing used for binaural output, so higher should be preferred. - **nSampleRate**: Sample rate of the streams to be processed. - **nSamples**: The maximum number of samples in an audio frame to be added to the stream. - **channelInfo**: Information about the expected stream formats. - **HRTFPath**: Path to an HRTF SOFA-file to be used when the output layout is binaural. - **reproductionScreen**: (Optional) Reproduction screen details used for screen scaling/locking. - **layoutPositions**: (Optional) Real polar positions for each of the loudspeaker in the layout. This is used if they do not exactly match the ITU specification. Note that they must be within the range allowed by the specification. > [!IMPORTANT] > When the renderer is configured for binaural output and the internal MIT HRTF > is used instead of SOFA, the binauralization will only work for 1st order ambisonics, > not for higher order ambisonics. ### AddObject `AddObject()` should be called for every Object stream to be rendered. Its corresponding `ObjectMetadata` should be supplied with it. This function can be called multiple times for each Object each time `GetRenderedAudio()` is called by using the offset parameter. However, care must be taken to ensure that each new call would not lead to the total number of samples added that frame going beyond the value nSamples set in `Configure()`. The inputs are: - **pIn** Pointer to the mono object buffer to be rendered. - **nSamples** Number of samples in the stream. - **metadata** Metadata for the object stream. - **nOffset** (Optional) Number of samples of delay to applied to the signal. ### AddHOA `AddHOA()` should be called for every HOA stream to be rendered. Its corresponding `HoaMetadata` should be supplied with it. This function can be called multiple times for each Object each time `GetRenderedAudio()` is called by using the offset parameter. However, care must be taken to ensure that each new call would not lead to the total number of samples added that frame going beyond the value nSamples set in `Configure()`. The inputs are: - **pHoaIn** The HOA audio buffers to be rendered of size nAmbiCh x nSamples - **nSamples** Number of samples in the stream. - **metadata** Metadata for the HOA stream. - **nOffset** (Optional) Number of samples of delay to applied to the signal. ### AddDirectSpeaker `AddDirectSpeaker()` should be called for every DirectSpeaker stream to be rendered. Its corresponding `DirectSpeakerMetadata` should be supplied with it. This function can be called multiple times for each Object each time `GetRenderedAudio()` is called by using the offset parameter. However, care must be taken to ensure that each new call would not lead to the total number of samples added that frame going beyond the value nSamples set in `Configure()`. The inputs are: - **pIn** Pointer to the mono DirectSpeaker buffer to be rendered. - **nSamples** Number of samples in the stream. - **metadata** Metadata for the DirectSpeaker stream. - **nOffset** (Optional) Number of samples of delay to applied to the signal. ### AddBinaural `AddBinaural()` should be called for every Binaural stream to be rendered. If the output format is not set to binaural then any audio added here is discarded. This function can be called multiple times for each Object each time `GetRenderedAudio()` is called by using the offset parameter. However, care must be taken to ensure that each new call would not lead to the total number of samples added that frame going beyond the value nSamples set in `Configure()`. The inputs are: - **pHoaIn** The binaural audio buffers to be rendered of size 2 x nSamples - **nSamples** Number of samples in the stream. - **nOffset** (Optional) Number of samples of delay to applied to the signal. ### GetRenderedAudio Get the rendered audio using `GetRenderedAudio()`. After it has been called all internal buffers are reset. Therefore, it is very important that this function only be called after all streams have been added. - **pRender** Rendered audio output. - **nSamples** The number of samples to get. ### Code Example This example renders an Object, HOA and DirectSpeaker stream to binaural. For each of the stream types the metadata is generated along with an audio stream. The `StreamInformation` used to configure `Renderer` is generated when the metadata is "read". `StreamInformation` keeps track of the total number of tracks as well as what type they have. Note that when the metadata is being generated the track indices must match the ordering with which the tracks are added to the `StreamInformation`. In this example an Object rotates around the listener (left, back, right and again to front), the HOA stream is encoded with a source at 90° and the DirectSpeaker corresponds to the right-wide loudspeaker placed at -60°. Replace the streams with your own mono audio to hear the motion clearer. ```c++ using namespace spaudio; const unsigned int sampleRate = 48000; const int nBlockLength = 512; const int nBlocks = 470; const int nSigSamples = nBlocks * nBlockLength; // Approximately 5 seconds @ 48 kHz // Ambisonic order const unsigned int nOrder = 3; // Prepare the stream to hold the rendered audio (binaural) const unsigned int nLdspk = 2; float** renderStream = new float* [nLdspk]; for (unsigned int i = 0; i < nLdspk; ++i) { renderStream[i] = new float[nSigSamples]; } // Track index for each channel in the streams unsigned int trackInd = 0; // The stream information used to configure Renderer StreamInformation streamInfo; // Add an object stream =============================================================================================== // Prepare the metadata for the stream ObjectMetadata objectMetadata; objectMetadata.trackInd = trackInd++; objectMetadata.blockLength = nBlockLength; objectMetadata.cartesian = false; // Channel lock (off by default) objectMetadata.channelLock = ChannelLock(); objectMetadata.channelLock->maxDistance = 0.f; // <- Increase this to see the signal snap to fully in the left loudspeaker // Object divergence (off by default) objectMetadata.objectDivergence = ObjectDivergence(); objectMetadata.objectDivergence->azimuthRange = 30.; // <- Controls the width of the divergence objectMetadata.objectDivergence->value = 0.; // <- Increase this to apply object divergence // Object extent (off by default) objectMetadata.width = 0.; // <- Increase this to increase the width and spread the Object over more adjacent loudspeakers // Configure the stream information. In this case there is only a single channel stream streamInfo.nChannels++; streamInfo.typeDefinition.push_back(TypeDefinition::Objects); std::vector objectStream(nSigSamples); // Fill the vector with a sine wave for (int i = 0; i < nSigSamples; ++i) objectStream[i] = (float)std::sin((float)M_PI * 2.f * 440.f * (float)i / (float)sampleRate); // Add an HOA stream =============================================================================================== const unsigned int nHoaCh = OrderToComponents(nOrder, true); // Set the fade time to the length of one block const float fadeTimeInMilliSec = 0.f; std::vector hoaSinewave(nSigSamples); // Fill the vector with a sine wave for (int i = 0; i < nSigSamples; ++i) hoaSinewave[i] = (float)std::sin((float)M_PI * 2.f * 700.f * (float)i / (float)sampleRate); // Destination B-format buffer BFormat myBFormat; myBFormat.Configure(nOrder, true, nSigSamples); myBFormat.Reset(); // Set up and configure the Ambisonics encoder AmbisonicEncoder myEncoder; myEncoder.Configure(nOrder, true, sampleRate, fadeTimeInMilliSec); // Set test signal's initial direction in the sound field PolarPosition position; position.azimuth = 0.5f * (float)M_PI; position.elevation = 0; position.distance = 1.f; myEncoder.SetPosition(position); myEncoder.Reset(); myEncoder.Process(hoaSinewave.data(), nSigSamples, &myBFormat); // Prepare the stream to be processed by the renderer float** hoaStream = new float* [nHoaCh]; for (unsigned int i = 0; i < nHoaCh; ++i) { hoaStream[i] = new float[nSigSamples]; myBFormat.ExtractStream(&hoaStream[i][0], i, nSigSamples); } // Prepare the metadata for the stream HoaMetadata hoaMetadata; hoaMetadata.normalization = "SN3D"; // Configure the stream information. In this case there is only a single HOA stream of (nOrder + 1)^2 channels for (unsigned int i = 0; i < nHoaCh; ++i) { streamInfo.nChannels++; streamInfo.typeDefinition.push_back(TypeDefinition::HOA); // Set the metadata for each channel int order, degree; ComponentToOrderAndDegree(i, true, order, degree); hoaMetadata.degrees.push_back(degree); hoaMetadata.orders.push_back(order); hoaMetadata.trackInds.push_back(trackInd++); } // Add a DirectSpeaker stream =============================================================================================== std::vector speakerSinewave(nSigSamples); // Fill the vector with a sine wave for (int i = 0; i < nSigSamples; ++i) speakerSinewave[i] = (float)std::sin((float)M_PI * 2.f * 185.f * (float)i / (float)sampleRate); // Prepare the metadata for the stream DirectSpeakerMetadata directSpeakerMetadata; directSpeakerMetadata.trackInd = trackInd++; directSpeakerMetadata.speakerLabel = "M-060"; // Wide-right speaker directSpeakerMetadata.audioPackFormatID = std::string("AP_00010009"); // 9+10+3 layout // Configure the stream information. In this case there is only a single channel stream streamInfo.nChannels++; streamInfo.typeDefinition.push_back(TypeDefinition::DirectSpeakers); // Render the stream =============================================================================================== // Set up the Renderer Renderer renderer; renderer.Configure(OutputLayout::Binaural, nOrder, sampleRate, nBlockLength, streamInfo); float** renderBlock = new float* [2]; float** hoaBlock = new float* [nHoaCh]; for (int iBlock = 0; iBlock < nBlocks; ++iBlock) { const unsigned int iSamp = iBlock * nBlockLength; // Get "new" Object metadata objectMetadata.position.polarPosition().azimuth = (double)iBlock / (double)nBlocks * 360.; // Add the Object stream to be rendered renderer.AddObject(&objectStream[iSamp], nBlockLength, objectMetadata); // Add the HOA stream to be rendered for (unsigned int i = 0; i < nHoaCh; ++i) hoaBlock[i] = &hoaStream[i][iSamp]; renderer.AddHoa(hoaBlock, nBlockLength, hoaMetadata); // Add the DirectSpeaker stream to be rendered renderer.AddDirectSpeaker(&speakerSinewave[iSamp], nBlockLength, directSpeakerMetadata); // Render the stream renderBlock[0] = &renderStream[0][iSamp]; renderBlock[1] = &renderStream[1][iSamp]; renderer.GetRenderedAudio(renderBlock, nBlockLength); } // Cleanup for (unsigned i = 0; i < nHoaCh; ++i) delete[] hoaStream[i]; delete[] hoaStream; for (unsigned i = 0; i < nLdspk; ++i) delete[] renderStream[i]; delete[] renderStream; delete[] renderBlock; delete[] hoaBlock; ``` ## References [1] International Telecommunication Union. Audio Definition Model renderer for advanced sound systems. International Telecommunication Union, Geneva, Switzerland, Recommendation ITU-R BS.2127-1 edition, 2023. URL . [2] Alliance for Open Media. Interactive Audio Metadata Format (IAMF) Version 1.0.0 - Errata, 2024. URL: . Accessed: 2024-09-04. [3] European Broadcasting Union. EBU Tech 3369: Binaral EBU ADM Renderer (BEAR) for Object-Based Sound Over Headphones, Geneva, Switzerland, 2023. URL . videolan-libspatialaudio-2d42ddf/docs/doxygen/000077500000000000000000000000001511423056100215555ustar00rootroot00000000000000videolan-libspatialaudio-2d42ddf/docs/doxygen/Doxyfile000066400000000000000000003723731511423056100233020ustar00rootroot00000000000000# Doxyfile 1.9.8 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). # # Note: # # Use doxygen to compare the used configuration file with the template # configuration file: # doxygen -x [configFile] # Use doxygen to compare the used configuration file with the template # configuration file without replacing the environment variables or CMake type # replacement variables: # doxygen -x_noenv [configFile] #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the configuration # file that follow. The default is UTF-8 which is also the encoding used for all # text before the first occurrence of this tag. Doxygen uses libiconv (or the # iconv built into libc) for the transcoding. See # https://www.gnu.org/software/libiconv/ for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = libspatialaudio # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = "A C++ library for Ambisonic and object-based audio spatialisation" # With the PROJECT_LOGO tag one can specify a logo or an icon that is included # in the documentation. The maximum height of the logo should not exceed 55 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = . # If the CREATE_SUBDIRS tag is set to YES then doxygen will create up to 4096 # sub-directories (in 2 levels) under the output directory of each output format # and will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. Adapt CREATE_SUBDIRS_LEVEL to # control the number of sub-directories. # The default value is: NO. CREATE_SUBDIRS = NO # Controls the number of sub-directories that will be created when # CREATE_SUBDIRS tag is set to YES. Level 0 represents 16 directories, and every # level increment doubles the number of directories, resulting in 4096 # directories at level 8 which is the default and also the maximum value. The # sub-directories are organized in 2 levels, the first level always has a fixed # number of 16 directories. # Minimum value: 0, maximum value: 8, default value: 8. # This tag requires that the tag CREATE_SUBDIRS is set to YES. CREATE_SUBDIRS_LEVEL = 8 # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII # characters to appear in the names of generated files. If set to NO, non-ASCII # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode # U+3044. # The default value is: NO. ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Bulgarian, # Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, English # (United States), Esperanto, Farsi (Persian), Finnish, French, German, Greek, # Hindi, Hungarian, Indonesian, Italian, Japanese, Japanese-en (Japanese with # English messages), Korean, Korean-en (Korean with English messages), Latvian, # Lithuanian, Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, # Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, # Swedish, Turkish, Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = "The $name class" \ "The $name widget" \ "The $name file" \ is \ provides \ specifies \ contains \ represents \ a \ an \ the # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. # The default value is: NO. INLINE_INHERITED_MEMB = NO # If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path # before files name in the file list and in the header files. If set to NO the # shortest path that makes the file name unique will be used # The default value is: YES. FULL_PATH_NAMES = YES # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. # Stripping is only done if one of the specified strings matches the left-hand # part of the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the path to # strip. # # Note that you can specify absolute paths here, but also relative paths, which # will be relative from the directory where doxygen is started. # This tag requires that the tag FULL_PATH_NAMES is set to YES. STRIP_FROM_PATH = # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the # path mentioned in the documentation of a class, which tells the reader which # header file to include in order to use a class. If left blank only the name of # the header file containing the class definition is used. Otherwise one should # specify the list of include paths that are normally passed to the compiler # using the -I flag. STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but # less readable) file names. This can be useful is your file systems doesn't # support long names like on DOS, Mac, or CD-ROM. # The default value is: NO. SHORT_NAMES = NO # If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the # first line (until the first dot) of a Javadoc-style comment as the brief # description. If set to NO, the Javadoc-style will behave just like regular Qt- # style comments (thus requiring an explicit @brief command for a brief # description.) # The default value is: NO. JAVADOC_AUTOBRIEF = NO # If the JAVADOC_BANNER tag is set to YES then doxygen will interpret a line # such as # /*************** # as being the beginning of a Javadoc-style comment "banner". If set to NO, the # Javadoc-style will behave just like regular comments and it will not be # interpreted by doxygen. # The default value is: NO. JAVADOC_BANNER = NO # If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first # line (until the first dot) of a Qt-style comment as the brief description. If # set to NO, the Qt-style will behave just like regular Qt-style comments (thus # requiring an explicit \brief command for a brief description.) # The default value is: NO. QT_AUTOBRIEF = NO # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a # multi-line C++ special comment block (i.e. a block of //! or /// comments) as # a brief description. This used to be the default behavior. The new default is # to treat a multi-line C++ comment block as a detailed description. Set this # tag to YES if you prefer the old behavior instead. # # Note that setting this tag to YES also means that rational rose comments are # not recognized any more. # The default value is: NO. MULTILINE_CPP_IS_BRIEF = NO # By default Python docstrings are displayed as preformatted text and doxygen's # special commands cannot be used. By setting PYTHON_DOCSTRING to NO the # doxygen's special commands can be used and the contents of the docstring # documentation blocks is shown as doxygen documentation. # The default value is: YES. PYTHON_DOCSTRING = YES # If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the # documentation from any documented member that it re-implements. # The default value is: YES. INHERIT_DOCS = YES # If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new # page for each member. If set to NO, the documentation of a member will be part # of the file/class/namespace that contains it. # The default value is: NO. SEPARATE_MEMBER_PAGES = NO # The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen # uses this value to replace tabs by spaces in code fragments. # Minimum value: 1, maximum value: 16, default value: 4. TAB_SIZE = 4 # This tag can be used to specify a number of aliases that act as commands in # the documentation. An alias has the form: # name=value # For example adding # "sideeffect=@par Side Effects:^^" # will allow you to put the command \sideeffect (or @sideeffect) in the # documentation, which will result in a user-defined paragraph with heading # "Side Effects:". Note that you cannot put \n's in the value part of an alias # to insert newlines (in the resulting output). You can put ^^ in the value part # of an alias to insert a newline as if a physical newline was in the original # file. When you need a literal { or } or , in the value part of an alias you # have to escape them by means of a backslash (\), this can lead to conflicts # with the commands \{ and \} for these it is advised to use the version @{ and # @} or use a double escape (\\{ and \\}) ALIASES = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. For # instance, some of the names that are used will be different. The list of all # members will be omitted, etc. # The default value is: NO. OPTIMIZE_OUTPUT_FOR_C = NO # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or # Python sources only. Doxygen will then generate output that is more tailored # for that language. For instance, namespaces will be presented as packages, # qualified scopes will look different, etc. # The default value is: NO. OPTIMIZE_OUTPUT_JAVA = NO # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran # sources. Doxygen will then generate output that is tailored for Fortran. # The default value is: NO. OPTIMIZE_FOR_FORTRAN = NO # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL # sources. Doxygen will then generate output that is tailored for VHDL. # The default value is: NO. OPTIMIZE_OUTPUT_VHDL = NO # Set the OPTIMIZE_OUTPUT_SLICE tag to YES if your project consists of Slice # sources only. Doxygen will then generate output that is more tailored for that # language. For instance, namespaces will be presented as modules, types will be # separated into more groups, etc. # The default value is: NO. OPTIMIZE_OUTPUT_SLICE = NO # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given # extension. Doxygen has a built-in mapping, but you can override or extend it # using this tag. The format is ext=language, where ext is a file extension, and # language is one of the parsers supported by doxygen: IDL, Java, JavaScript, # Csharp (C#), C, C++, Lex, D, PHP, md (Markdown), Objective-C, Python, Slice, # VHDL, Fortran (fixed format Fortran: FortranFixed, free formatted Fortran: # FortranFree, unknown formatted Fortran: Fortran. In the later case the parser # tries to guess whether the code is fixed or free formatted code, this is the # default for Fortran type files). For instance to make doxygen treat .inc files # as Fortran files (default is PHP), and .f files as C (default is Fortran), # use: inc=Fortran f=C. # # Note: For files without extension you can use no_extension as a placeholder. # # Note that for custom extensions you also need to set FILE_PATTERNS otherwise # the files are not read by doxygen. When specifying no_extension you should add # * to the FILE_PATTERNS. # # Note see also the list of default file extension mappings. EXTENSION_MAPPING = # If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments # according to the Markdown format, which allows for more readable # documentation. See https://daringfireball.net/projects/markdown/ for details. # The output of markdown processing is further processed by doxygen, so you can # mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in # case of backward compatibilities issues. # The default value is: YES. MARKDOWN_SUPPORT = YES # When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings up # to that level are automatically included in the table of contents, even if # they do not have an id attribute. # Note: This feature currently applies only to Markdown headings. # Minimum value: 0, maximum value: 99, default value: 5. # This tag requires that the tag MARKDOWN_SUPPORT is set to YES. TOC_INCLUDE_HEADINGS = 5 # The MARKDOWN_ID_STYLE tag can be used to specify the algorithm used to # generate identifiers for the Markdown headings. Note: Every identifier is # unique. # Possible values are: DOXYGEN use a fixed 'autotoc_md' string followed by a # sequence number starting at 0 and GITHUB use the lower case version of title # with any whitespace replaced by '-' and punctuation characters removed. # The default value is: DOXYGEN. # This tag requires that the tag MARKDOWN_SUPPORT is set to YES. MARKDOWN_ID_STYLE = DOXYGEN # When enabled doxygen tries to link words that correspond to documented # classes, or namespaces to their corresponding documentation. Such a link can # be prevented in individual cases by putting a % sign in front of the word or # globally by setting AUTOLINK_SUPPORT to NO. # The default value is: YES. AUTOLINK_SUPPORT = YES # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should set this # tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); # versus func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. # The default value is: NO. BUILTIN_STL_SUPPORT = NO # If you use Microsoft's C++/CLI language, you should set this option to YES to # enable parsing support. # The default value is: NO. CPP_CLI_SUPPORT = NO # Set the SIP_SUPPORT tag to YES if your project consists of sip (see: # https://www.riverbankcomputing.com/software/sip/intro) sources only. Doxygen # will parse them like normal C++ but will assume all classes use public instead # of private inheritance when no explicit protection keyword is present. # The default value is: NO. SIP_SUPPORT = NO # For Microsoft's IDL there are propget and propput attributes to indicate # getter and setter methods for a property. Setting this option to YES will make # doxygen to replace the get and set methods by a property in the documentation. # This will only work if the methods are indeed getting or setting a simple # type. If this is not the case, or you want to show the methods anyway, you # should set this option to NO. # The default value is: YES. IDL_PROPERTY_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. # The default value is: NO. DISTRIBUTE_GROUP_DOC = NO # If one adds a struct or class to a group and this option is enabled, then also # any nested class or struct is added to the same group. By default this option # is disabled and one has to add nested compounds explicitly via \ingroup. # The default value is: NO. GROUP_NESTED_COMPOUNDS = NO # Set the SUBGROUPING tag to YES to allow class member groups of the same type # (for instance a group of public functions) to be put as a subgroup of that # type (e.g. under the Public Functions section). Set it to NO to prevent # subgrouping. Alternatively, this can be done per class using the # \nosubgrouping command. # The default value is: YES. SUBGROUPING = YES # When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions # are shown inside the group in which they are included (e.g. using \ingroup) # instead of on a separate page (for HTML and Man pages) or section (for LaTeX # and RTF). # # Note that this feature does not work in combination with # SEPARATE_MEMBER_PAGES. # The default value is: NO. INLINE_GROUPED_CLASSES = NO # When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions # with only public data fields or simple typedef fields will be shown inline in # the documentation of the scope in which they are defined (i.e. file, # namespace, or group documentation), provided this scope is documented. If set # to NO, structs, classes, and unions are shown on a separate page (for HTML and # Man pages) or section (for LaTeX and RTF). # The default value is: NO. INLINE_SIMPLE_STRUCTS = NO # When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or # enum is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct # with name TypeT. When disabled the typedef will appear as a member of a file, # namespace, or class. And the struct will be named TypeS. This can typically be # useful for C code in case the coding convention dictates that all compound # types are typedef'ed and only the typedef is referenced, never the tag name. # The default value is: NO. TYPEDEF_HIDES_STRUCT = NO # The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This # cache is used to resolve symbols given their name and scope. Since this can be # an expensive process and often the same symbol appears multiple times in the # code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small # doxygen will become slower. If the cache is too large, memory is wasted. The # cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range # is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 # symbols. At the end of a run doxygen will report the cache usage and suggest # the optimal cache size from a speed point of view. # Minimum value: 0, maximum value: 9, default value: 0. LOOKUP_CACHE_SIZE = 0 # The NUM_PROC_THREADS specifies the number of threads doxygen is allowed to use # during processing. When set to 0 doxygen will based this on the number of # cores available in the system. You can set it explicitly to a value larger # than 0 to get more control over the balance between CPU load and processing # speed. At this moment only the input processing can be done using multiple # threads. Since this is still an experimental feature the default is set to 1, # which effectively disables parallel processing. Please report any issues you # encounter. Generating dot graphs in parallel is controlled by the # DOT_NUM_THREADS setting. # Minimum value: 0, maximum value: 32, default value: 1. NUM_PROC_THREADS = 1 # If the TIMESTAMP tag is set different from NO then each generated page will # contain the date or date and time when the page was generated. Setting this to # NO can help when comparing the output of multiple runs. # Possible values are: YES, NO, DATETIME and DATE. # The default value is: NO. TIMESTAMP = NO #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- # If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in # documentation are documented, even if no documentation was available. Private # class members and static file members will be hidden unless the # EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. # Note: This will also disable the warnings about undocumented members that are # normally produced when WARNINGS is set to YES. # The default value is: NO. EXTRACT_ALL = NO # If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will # be included in the documentation. # The default value is: NO. EXTRACT_PRIVATE = NO # If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual # methods of a class will be included in the documentation. # The default value is: NO. EXTRACT_PRIV_VIRTUAL = NO # If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal # scope will be included in the documentation. # The default value is: NO. EXTRACT_PACKAGE = NO # If the EXTRACT_STATIC tag is set to YES, all static members of a file will be # included in the documentation. # The default value is: NO. EXTRACT_STATIC = NO # If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined # locally in source files will be included in the documentation. If set to NO, # only classes defined in header files are included. Does not have any effect # for Java sources. # The default value is: YES. EXTRACT_LOCAL_CLASSES = YES # This flag is only useful for Objective-C code. If set to YES, local methods, # which are defined in the implementation section but not in the interface are # included in the documentation. If set to NO, only methods in the interface are # included. # The default value is: NO. EXTRACT_LOCAL_METHODS = NO # If this flag is set to YES, the members of anonymous namespaces will be # extracted and appear in the documentation as a namespace called # 'anonymous_namespace{file}', where file will be replaced with the base name of # the file that contains the anonymous namespace. By default anonymous namespace # are hidden. # The default value is: NO. EXTRACT_ANON_NSPACES = NO # If this flag is set to YES, the name of an unnamed parameter in a declaration # will be determined by the corresponding definition. By default unnamed # parameters remain unnamed in the output. # The default value is: YES. RESOLVE_UNNAMED_PARAMS = YES # If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all # undocumented members inside documented classes or files. If set to NO these # members will be included in the various overviews, but no documentation # section is generated. This option has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_MEMBERS = NO # If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all # undocumented classes that are normally visible in the class hierarchy. If set # to NO, these classes will be included in the various overviews. This option # will also hide undocumented C++ concepts if enabled. This option has no effect # if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_CLASSES = NO # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend # declarations. If set to NO, these declarations will be included in the # documentation. # The default value is: NO. HIDE_FRIEND_COMPOUNDS = NO # If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any # documentation blocks found inside the body of a function. If set to NO, these # blocks will be appended to the function's detailed documentation block. # The default value is: NO. HIDE_IN_BODY_DOCS = NO # The INTERNAL_DOCS tag determines if documentation that is typed after a # \internal command is included. If the tag is set to NO then the documentation # will be excluded. Set it to YES to include the internal documentation. # The default value is: NO. INTERNAL_DOCS = NO # With the correct setting of option CASE_SENSE_NAMES doxygen will better be # able to match the capabilities of the underlying filesystem. In case the # filesystem is case sensitive (i.e. it supports files in the same directory # whose names only differ in casing), the option must be set to YES to properly # deal with such files in case they appear in the input. For filesystems that # are not case sensitive the option should be set to NO to properly deal with # output files written for symbols that only differ in casing, such as for two # classes, one named CLASS and the other named Class, and to also support # references to files without having to specify the exact matching casing. On # Windows (including Cygwin) and MacOS, users should typically set this option # to NO, whereas on Linux or other Unix flavors it should typically be set to # YES. # Possible values are: SYSTEM, NO and YES. # The default value is: SYSTEM. CASE_SENSE_NAMES = SYSTEM # If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with # their full class and namespace scopes in the documentation. If set to YES, the # scope will be hidden. # The default value is: NO. HIDE_SCOPE_NAMES = NO # If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will # append additional text to a page's title, such as Class Reference. If set to # YES the compound reference will be hidden. # The default value is: NO. HIDE_COMPOUND_REFERENCE= NO # If the SHOW_HEADERFILE tag is set to YES then the documentation for a class # will show which file needs to be included to use the class. # The default value is: YES. SHOW_HEADERFILE = YES # If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of # the files that are included by a file in the documentation of that file. # The default value is: YES. SHOW_INCLUDE_FILES = YES # If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each # grouped member an include statement to the documentation, telling the reader # which file to include in order to use the member. # The default value is: NO. SHOW_GROUPED_MEMB_INC = NO # If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include # files with double quotes in the documentation rather than with sharp brackets. # The default value is: NO. FORCE_LOCAL_INCLUDES = NO # If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the # documentation for inline members. # The default value is: YES. INLINE_INFO = YES # If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the # (detailed) documentation of file and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. # The default value is: YES. SORT_MEMBER_DOCS = YES # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief # descriptions of file, namespace and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. Note that # this will also influence the order of the classes in the class list. # The default value is: NO. SORT_BRIEF_DOCS = NO # If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the # (brief and detailed) documentation of class members so that constructors and # destructors are listed first. If set to NO the constructors will appear in the # respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. # Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief # member documentation. # Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting # detailed member documentation. # The default value is: NO. SORT_MEMBERS_CTORS_1ST = NO # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy # of group names into alphabetical order. If set to NO the group names will # appear in their defined order. # The default value is: NO. SORT_GROUP_NAMES = NO # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by # fully-qualified names, including namespaces. If set to NO, the class list will # be sorted only by class name, not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. # Note: This option applies only to the class list, not to the alphabetical # list. # The default value is: NO. SORT_BY_SCOPE_NAME = NO # If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper # type resolution of all parameters of a function it will reject a match between # the prototype and the implementation of a member function even if there is # only one candidate or it is obvious which candidate to choose by doing a # simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still # accept a match between prototype and implementation in such cases. # The default value is: NO. STRICT_PROTO_MATCHING = NO # The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo # list. This list is created by putting \todo commands in the documentation. # The default value is: YES. GENERATE_TODOLIST = YES # The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test # list. This list is created by putting \test commands in the documentation. # The default value is: YES. GENERATE_TESTLIST = YES # The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug # list. This list is created by putting \bug commands in the documentation. # The default value is: YES. GENERATE_BUGLIST = YES # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) # the deprecated list. This list is created by putting \deprecated commands in # the documentation. # The default value is: YES. GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional documentation # sections, marked by \if ... \endif and \cond # ... \endcond blocks. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the # initial value of a variable or macro / define can have for it to appear in the # documentation. If the initializer consists of more lines than specified here # it will be hidden. Use a value of 0 to hide initializers completely. The # appearance of the value of individual variables and macros / defines can be # controlled using \showinitializer or \hideinitializer command in the # documentation regardless of this setting. # Minimum value: 0, maximum value: 10000, default value: 30. MAX_INITIALIZER_LINES = 30 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated at # the bottom of the documentation of classes and structs. If set to YES, the # list will mention the files that were used to generate the documentation. # The default value is: YES. SHOW_USED_FILES = YES # Set the SHOW_FILES tag to NO to disable the generation of the Files page. This # will remove the Files entry from the Quick Index and from the Folder Tree View # (if specified). # The default value is: YES. SHOW_FILES = YES # Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces # page. This will remove the Namespaces entry from the Quick Index and from the # Folder Tree View (if specified). # The default value is: YES. SHOW_NAMESPACES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from # the version control system). Doxygen will invoke the program by executing (via # popen()) the command command input-file, where command is the value of the # FILE_VERSION_FILTER tag, and input-file is the name of an input file provided # by doxygen. Whatever the program writes to standard output is used as the file # version. For an example see the documentation. FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated # output files in an output format independent way. To create the layout file # that represents doxygen's defaults, run doxygen with the -l option. You can # optionally specify a file name after the option, if omitted DoxygenLayout.xml # will be used as the name of the layout file. See also section "Changing the # layout of pages" for information. # # Note that if you run doxygen from a directory containing a file called # DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE # tag is left empty. LAYOUT_FILE = # The CITE_BIB_FILES tag can be used to specify one or more bib files containing # the reference definitions. This must be a list of .bib files. The .bib # extension is automatically appended if omitted. This requires the bibtex tool # to be installed. See also https://en.wikipedia.org/wiki/BibTeX for more info. # For LaTeX the style of the bibliography can be controlled using # LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the # search path. See also \cite for info how to create references. CITE_BIB_FILES = #--------------------------------------------------------------------------- # Configuration options related to warning and progress messages #--------------------------------------------------------------------------- # The QUIET tag can be used to turn on/off the messages that are generated to # standard output by doxygen. If QUIET is set to YES this implies that the # messages are off. # The default value is: NO. QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are # generated to standard error (stderr) by doxygen. If WARNINGS is set to YES # this implies that the warnings are on. # # Tip: Turn warnings on while writing the documentation. # The default value is: YES. WARNINGS = YES # If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate # warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag # will automatically be disabled. # The default value is: YES. WARN_IF_UNDOCUMENTED = YES # If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for # potential errors in the documentation, such as documenting some parameters in # a documented function twice, or documenting parameters that don't exist or # using markup commands wrongly. # The default value is: YES. WARN_IF_DOC_ERROR = YES # If WARN_IF_INCOMPLETE_DOC is set to YES, doxygen will warn about incomplete # function parameter documentation. If set to NO, doxygen will accept that some # parameters have no documentation without warning. # The default value is: YES. WARN_IF_INCOMPLETE_DOC = YES # This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that # are documented, but have no documentation for their parameters or return # value. If set to NO, doxygen will only warn about wrong parameter # documentation, but not about the absence of documentation. If EXTRACT_ALL is # set to YES then this flag will automatically be disabled. See also # WARN_IF_INCOMPLETE_DOC # The default value is: NO. WARN_NO_PARAMDOC = NO # If WARN_IF_UNDOC_ENUM_VAL option is set to YES, doxygen will warn about # undocumented enumeration values. If set to NO, doxygen will accept # undocumented enumeration values. If EXTRACT_ALL is set to YES then this flag # will automatically be disabled. # The default value is: NO. WARN_IF_UNDOC_ENUM_VAL = NO # If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when # a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS # then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but # at the end of the doxygen process doxygen will return with a non-zero status. # If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS_PRINT then doxygen behaves # like FAIL_ON_WARNINGS but in case no WARN_LOGFILE is defined doxygen will not # write the warning messages in between other messages but write them at the end # of a run, in case a WARN_LOGFILE is defined the warning messages will be # besides being in the defined file also be shown at the end of a run, unless # the WARN_LOGFILE is defined as - i.e. standard output (stdout) in that case # the behavior will remain as with the setting FAIL_ON_WARNINGS. # Possible values are: NO, YES, FAIL_ON_WARNINGS and FAIL_ON_WARNINGS_PRINT. # The default value is: NO. WARN_AS_ERROR = NO # The WARN_FORMAT tag determines the format of the warning messages that doxygen # can produce. The string should contain the $file, $line, and $text tags, which # will be replaced by the file and line number from which the warning originated # and the warning text. Optionally the format may contain $version, which will # be replaced by the version of the file (if it could be obtained via # FILE_VERSION_FILTER) # See also: WARN_LINE_FORMAT # The default value is: $file:$line: $text. WARN_FORMAT = "$file:$line: $text" # In the $text part of the WARN_FORMAT command it is possible that a reference # to a more specific place is given. To make it easier to jump to this place # (outside of doxygen) the user can define a custom "cut" / "paste" string. # Example: # WARN_LINE_FORMAT = "'vi $file +$line'" # See also: WARN_FORMAT # The default value is: at line $line of file $file. WARN_LINE_FORMAT = "at line $line of file $file" # The WARN_LOGFILE tag can be used to specify a file to which warning and error # messages should be written. If left blank the output is written to standard # error (stderr). In case the file specified cannot be opened for writing the # warning and error messages are written to standard error. When as file - is # specified the warning and error messages are written to standard output # (stdout). WARN_LOGFILE = #--------------------------------------------------------------------------- # Configuration options related to the input files #--------------------------------------------------------------------------- # The INPUT tag is used to specify the files and/or directories that contain # documented source files. You may enter file names like myfile.cpp or # directories like /usr/src/myproject. Separate the files or directories with # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING # Note: If this tag is empty the current directory is searched. INPUT = ../../ # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses # libiconv (or the iconv built into libc) for the transcoding. See the libiconv # documentation (see: # https://www.gnu.org/software/libiconv/) for the list of possible encodings. # See also: INPUT_FILE_ENCODING # The default value is: UTF-8. INPUT_ENCODING = UTF-8 # This tag can be used to specify the character encoding of the source files # that doxygen parses The INPUT_FILE_ENCODING tag can be used to specify # character encoding on a per file pattern basis. Doxygen will compare the file # name with each pattern and apply the encoding instead of the default # INPUT_ENCODING) if there is a match. The character encodings are a list of the # form: pattern=encoding (like *.php=ISO-8859-1). See cfg_input_encoding # "INPUT_ENCODING" for further information on supported encodings. INPUT_FILE_ENCODING = # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and # *.h) to filter out the source-files in the directories. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # read by doxygen. # # Note the list of default checked file patterns might differ from the list of # default file extension mappings. # # If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cxxm, # *.cpp, *.cppm, *.c++, *.c++m, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, # *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp, *.h++, *.ixx, *.l, *.cs, *.d, *.php, # *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown, *.md, *.mm, *.dox (to be # provided as doxygen C comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, # *.f18, *.f, *.for, *.vhd, *.vhdl, *.ucf, *.qsf and *.ice. FILE_PATTERNS = *.c \ *.cc \ *.cxx \ *.cxxm \ *.cpp \ *.cppm \ *.c++ \ *.c++m \ *.java \ *.ii \ *.ixx \ *.ipp \ *.i++ \ *.inl \ *.idl \ *.ddl \ *.odl \ *.h \ *.hh \ *.hxx \ *.hpp \ *.h++ \ *.ixx \ *.l \ *.cs \ *.d \ *.php \ *.php4 \ *.php5 \ *.phtml \ *.inc \ *.m \ *.markdown \ *.md \ *.mm \ *.dox \ *.py \ *.pyw \ *.f90 \ *.f95 \ *.f03 \ *.f08 \ *.f18 \ *.f \ *.for \ *.vhd \ *.vhdl \ *.ucf \ *.qsf \ *.ice # The RECURSIVE tag can be used to specify whether or not subdirectories should # be searched for input files as well. # The default value is: NO. RECURSIVE = YES # The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. # # Note that relative paths are relative to the directory from which doxygen is # run. EXCLUDE = # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded # from the input. # The default value is: NO. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the # output. The symbol name can be a fully qualified name, a word, or if the # wildcard * is used, a substring. Examples: ANamespace, AClass, # ANamespace::AClass, ANamespace::*Test EXCLUDE_SYMBOLS = # The EXAMPLE_PATH tag can be used to specify one or more files or directories # that contain example code fragments that are included (see the \include # command). EXAMPLE_PATH = # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and # *.h) to filter out the source-files in the directories. If left blank all # files are included. EXAMPLE_PATTERNS = * # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be # searched for input files to be used with the \include or \dontinclude commands # irrespective of the value of the RECURSIVE tag. # The default value is: NO. EXAMPLE_RECURSIVE = NO # The IMAGE_PATH tag can be used to specify one or more files or directories # that contain images that are to be included in the documentation (see the # \image command). IMAGE_PATH = # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program # by executing (via popen()) the command: # # # # where is the value of the INPUT_FILTER tag, and is the # name of an input file. Doxygen will then use the output that the filter # program writes to standard output. If FILTER_PATTERNS is specified, this tag # will be ignored. # # Note that the filter must not add or remove lines; it is applied before the # code is scanned, but not when the output code is generated. If lines are added # or removed, the anchors will not be placed correctly. # # Note that doxygen will use the data processed and written to standard output # for further processing, therefore nothing else, like debug statements or used # commands (so in case of a Windows batch file always use @echo OFF), should be # written to standard output. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the # filter if there is a match. The filters are a list of the form: pattern=filter # (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how # filters are used. If the FILTER_PATTERNS tag is empty or if none of the # patterns match the file name, INPUT_FILTER is applied. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER) will also be used to filter the input files that are used for # producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). # The default value is: NO. FILTER_SOURCE_FILES = NO # The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file # pattern. A pattern will override the setting for FILTER_PATTERN (if any) and # it is also possible to disable source filtering for a specific pattern using # *.ext= (so without naming a filter). # This tag requires that the tag FILTER_SOURCE_FILES is set to YES. FILTER_SOURCE_PATTERNS = # If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that # is part of the input, its contents will be placed on the main page # (index.html). This can be useful if you have a project on for instance GitHub # and want to reuse the introduction page also for the doxygen output. USE_MDFILE_AS_MAINPAGE = README.md # The Fortran standard specifies that for fixed formatted Fortran code all # characters from position 72 are to be considered as comment. A common # extension is to allow longer lines before the automatic comment starts. The # setting FORTRAN_COMMENT_AFTER will also make it possible that longer lines can # be processed before the automatic comment starts. # Minimum value: 7, maximum value: 10000, default value: 72. FORTRAN_COMMENT_AFTER = 72 #--------------------------------------------------------------------------- # Configuration options related to source browsing #--------------------------------------------------------------------------- # If the SOURCE_BROWSER tag is set to YES then a list of source files will be # generated. Documented entities will be cross-referenced with these sources. # # Note: To get rid of all source code in the generated output, make sure that # also VERBATIM_HEADERS is set to NO. # The default value is: NO. SOURCE_BROWSER = NO # Setting the INLINE_SOURCES tag to YES will include the body of functions, # classes and enums directly into the documentation. # The default value is: NO. INLINE_SOURCES = NO # Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any # special comment blocks from generated source code fragments. Normal C, C++ and # Fortran comments will always remain visible. # The default value is: YES. STRIP_CODE_COMMENTS = YES # If the REFERENCED_BY_RELATION tag is set to YES then for each documented # entity all documented functions referencing it will be listed. # The default value is: NO. REFERENCED_BY_RELATION = NO # If the REFERENCES_RELATION tag is set to YES then for each documented function # all documented entities called/used by that function will be listed. # The default value is: NO. REFERENCES_RELATION = NO # If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set # to YES then the hyperlinks from functions in REFERENCES_RELATION and # REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will # link to the documentation. # The default value is: YES. REFERENCES_LINK_SOURCE = YES # If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the # source code will show a tooltip with additional information such as prototype, # brief description and links to the definition and documentation. Since this # will make the HTML file larger and loading of large files a bit slower, you # can opt to disable this feature. # The default value is: YES. # This tag requires that the tag SOURCE_BROWSER is set to YES. SOURCE_TOOLTIPS = YES # If the USE_HTAGS tag is set to YES then the references to source code will # point to the HTML generated by the htags(1) tool instead of doxygen built-in # source browser. The htags tool is part of GNU's global source tagging system # (see https://www.gnu.org/software/global/global.html). You will need version # 4.8.6 or higher. # # To use it do the following: # - Install the latest version of global # - Enable SOURCE_BROWSER and USE_HTAGS in the configuration file # - Make sure the INPUT points to the root of the source tree # - Run doxygen as normal # # Doxygen will invoke htags (and that will in turn invoke gtags), so these # tools must be available from the command line (i.e. in the search path). # # The result: instead of the source browser generated by doxygen, the links to # source code will now point to the output of htags. # The default value is: NO. # This tag requires that the tag SOURCE_BROWSER is set to YES. USE_HTAGS = NO # If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a # verbatim copy of the header file for each class for which an include is # specified. Set to NO to disable this. # See also: Section \class. # The default value is: YES. VERBATIM_HEADERS = YES # If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the # clang parser (see: # http://clang.llvm.org/) for more accurate parsing at the cost of reduced # performance. This can be particularly helpful with template rich C++ code for # which doxygen's built-in parser lacks the necessary type information. # Note: The availability of this option depends on whether or not doxygen was # generated with the -Duse_libclang=ON option for CMake. # The default value is: NO. CLANG_ASSISTED_PARSING = NO # If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_INC_PATHS # tag is set to YES then doxygen will add the directory of each input to the # include path. # The default value is: YES. # This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. CLANG_ADD_INC_PATHS = YES # If clang assisted parsing is enabled you can provide the compiler with command # line options that you would normally use when invoking the compiler. Note that # the include paths will already be set by doxygen for the files and directories # specified with INPUT and INCLUDE_PATH. # This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. CLANG_OPTIONS = # If clang assisted parsing is enabled you can provide the clang parser with the # path to the directory containing a file called compile_commands.json. This # file is the compilation database (see: # http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) containing the # options used when the source files were built. This is equivalent to # specifying the -p option to a clang tool, such as clang-check. These options # will then be passed to the parser. Any options specified with CLANG_OPTIONS # will be added as well. # Note: The availability of this option depends on whether or not doxygen was # generated with the -Duse_libclang=ON option for CMake. CLANG_DATABASE_PATH = #--------------------------------------------------------------------------- # Configuration options related to the alphabetical class index #--------------------------------------------------------------------------- # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all # compounds will be generated. Enable this if the project contains a lot of # classes, structs, unions or interfaces. # The default value is: YES. ALPHABETICAL_INDEX = YES # The IGNORE_PREFIX tag can be used to specify a prefix (or a list of prefixes) # that should be ignored while generating the index headers. The IGNORE_PREFIX # tag works for classes, function and member names. The entity will be placed in # the alphabetical list under the first letter of the entity name that remains # after removing the prefix. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. IGNORE_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the HTML output #--------------------------------------------------------------------------- # If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output # The default value is: YES. GENERATE_HTML = YES # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a # relative path is entered the value of OUTPUT_DIRECTORY will be put in front of # it. # The default directory is: html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_OUTPUT = html # The HTML_FILE_EXTENSION tag can be used to specify the file extension for each # generated HTML page (for example: .htm, .php, .asp). # The default value is: .html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a user-defined HTML header file for # each generated HTML page. If the tag is left blank doxygen will generate a # standard header. # # To get valid HTML the header file that includes any scripts and style sheets # that doxygen needs, which is dependent on the configuration options used (e.g. # the setting GENERATE_TREEVIEW). It is highly recommended to start with a # default header using # doxygen -w html new_header.html new_footer.html new_stylesheet.css # YourConfigFile # and then modify the file new_header.html. See also section "Doxygen usage" # for information on how to generate the default header that doxygen normally # uses. # Note: The header is subject to change so you typically have to regenerate the # default header when upgrading to a newer version of doxygen. For a description # of the possible markers and block names see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_HEADER = # The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each # generated HTML page. If the tag is left blank doxygen will generate a standard # footer. See HTML_HEADER for more information on how to generate a default # footer and what special commands can be used inside the footer. See also # section "Doxygen usage" for information on how to generate the default footer # that doxygen normally uses. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading style # sheet that is used by each HTML page. It can be used to fine-tune the look of # the HTML output. If left blank doxygen will generate a default style sheet. # See also section "Doxygen usage" for information on how to generate the style # sheet that doxygen normally uses. # Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as # it is more robust and this tag (HTML_STYLESHEET) will in the future become # obsolete. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_STYLESHEET = # The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined # cascading style sheets that are included after the standard style sheets # created by doxygen. Using this option one can overrule certain style aspects. # This is preferred over using HTML_STYLESHEET since it does not replace the # standard style sheet and is therefore more robust against future updates. # Doxygen will copy the style sheet files to the output directory. # Note: The order of the extra style sheet files is of importance (e.g. the last # style sheet in the list overrules the setting of the previous ones in the # list). # Note: Since the styling of scrollbars can currently not be overruled in # Webkit/Chromium, the styling will be left out of the default doxygen.css if # one or more extra stylesheets have been specified. So if scrollbar # customization is desired it has to be added explicitly. For an example see the # documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_STYLESHEET = # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note # that these files will be copied to the base HTML output directory. Use the # $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these # files. In the HTML_STYLESHEET file, use the file name only. Also note that the # files will be copied as-is; there are no commands or markers available. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_FILES = # The HTML_COLORSTYLE tag can be used to specify if the generated HTML output # should be rendered with a dark or light theme. # Possible values are: LIGHT always generate light mode output, DARK always # generate dark mode output, AUTO_LIGHT automatically set the mode according to # the user preference, use light mode if no preference is set (the default), # AUTO_DARK automatically set the mode according to the user preference, use # dark mode if no preference is set and TOGGLE allow to user to switch between # light and dark mode via a button. # The default value is: AUTO_LIGHT. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE = AUTO_LIGHT # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen # will adjust the colors in the style sheet and background images according to # this color. Hue is specified as an angle on a color-wheel, see # https://en.wikipedia.org/wiki/Hue for more information. For instance the value # 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 # purple, and 360 is red again. # Minimum value: 0, maximum value: 359, default value: 220. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_HUE = 220 # The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors # in the HTML output. For a value of 0 the output will use gray-scales only. A # value of 255 will produce the most vivid colors. # Minimum value: 0, maximum value: 255, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_SAT = 100 # The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the # luminance component of the colors in the HTML output. Values below 100 # gradually make the output lighter, whereas values above 100 make the output # darker. The value divided by 100 is the actual gamma applied, so 80 represents # a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not # change the gamma. # Minimum value: 40, maximum value: 240, default value: 80. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_GAMMA = 80 # If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML # documentation will contain a main index with vertical navigation menus that # are dynamically created via JavaScript. If disabled, the navigation index will # consists of multiple levels of tabs that are statically embedded in every HTML # page. Disable this option to support browsers that do not have JavaScript, # like the Qt help browser. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_MENUS = YES # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the # page has loaded. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_SECTIONS = NO # If the HTML_CODE_FOLDING tag is set to YES then classes and functions can be # dynamically folded and expanded in the generated HTML source code. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_CODE_FOLDING = YES # With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries # shown in the various tree structured indices initially; the user can expand # and collapse entries dynamically later on. Doxygen will expand the tree to # such a level that at most the specified number of entries are visible (unless # a fully collapsed tree already exceeds this amount). So setting the number of # entries 1 will produce a full collapsed tree by default. 0 is a special value # representing an infinite number of entries and will result in a full expanded # tree by default. # Minimum value: 0, maximum value: 9999, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_INDEX_NUM_ENTRIES = 100 # If the GENERATE_DOCSET tag is set to YES, additional index files will be # generated that can be used as input for Apple's Xcode 3 integrated development # environment (see: # https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To # create a documentation set, doxygen will generate a Makefile in the HTML # output directory. Running make will produce the docset in that directory and # running make install will install the docset in # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at # startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy # genXcode/_index.html for more information. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_DOCSET = NO # This tag determines the name of the docset feed. A documentation feed provides # an umbrella under which multiple documentation sets from a single provider # (such as a company or product suite) can be grouped. # The default value is: Doxygen generated docs. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDNAME = "Doxygen generated docs" # This tag determines the URL of the docset feed. A documentation feed provides # an umbrella under which multiple documentation sets from a single provider # (such as a company or product suite) can be grouped. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDURL = # This tag specifies a string that should uniquely identify the documentation # set bundle. This should be a reverse domain-name style string, e.g. # com.mycompany.MyDocSet. Doxygen will append .docset to the name. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_BUNDLE_ID = org.doxygen.Project # The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify # the documentation publisher. This should be a reverse domain-name style # string, e.g. com.mycompany.MyDocSet.documentation. # The default value is: org.doxygen.Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_ID = org.doxygen.Publisher # The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. # The default value is: Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_NAME = Publisher # If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three # additional HTML index files: index.hhp, index.hhc, and index.hhk. The # index.hhp is a project file that can be read by Microsoft's HTML Help Workshop # on Windows. In the beginning of 2021 Microsoft took the original page, with # a.o. the download links, offline the HTML help workshop was already many years # in maintenance mode). You can download the HTML help workshop from the web # archives at Installation executable (see: # http://web.archive.org/web/20160201063255/http://download.microsoft.com/downlo # ad/0/A/9/0A939EF6-E31C-430F-A3DF-DFAE7960D564/htmlhelp.exe). # # The HTML Help Workshop contains a compiler that can convert all HTML output # generated by doxygen into a single compiled HTML file (.chm). Compiled HTML # files are now used as the Windows 98 help format, and will replace the old # Windows help format (.hlp) on all Windows platforms in the future. Compressed # HTML files also contain an index, a table of contents, and you can search for # words in the documentation. The HTML workshop also contains a viewer for # compressed HTML files. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_HTMLHELP = NO # The CHM_FILE tag can be used to specify the file name of the resulting .chm # file. You can add a path in front of the file if the result should not be # written to the html output directory. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_FILE = # The HHC_LOCATION tag can be used to specify the location (absolute path # including file name) of the HTML help compiler (hhc.exe). If non-empty, # doxygen will try to run the HTML help compiler on the generated index.hhp. # The file has to be specified with full path. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. HHC_LOCATION = # The GENERATE_CHI flag controls if a separate .chi index file is generated # (YES) or that it should be included in the main .chm file (NO). # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. GENERATE_CHI = NO # The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) # and project file content. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_INDEX_ENCODING = # The BINARY_TOC flag controls whether a binary table of contents is generated # (YES) or a normal table of contents (NO) in the .chm file. Furthermore it # enables the Previous and Next buttons. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. BINARY_TOC = NO # The TOC_EXPAND flag can be set to YES to add extra items for group members to # the table of contents of the HTML help documentation and to the tree view. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. TOC_EXPAND = NO # The SITEMAP_URL tag is used to specify the full URL of the place where the # generated documentation will be placed on the server by the user during the # deployment of the documentation. The generated sitemap is called sitemap.xml # and placed on the directory specified by HTML_OUTPUT. In case no SITEMAP_URL # is specified no sitemap is generated. For information about the sitemap # protocol see https://www.sitemaps.org # This tag requires that the tag GENERATE_HTML is set to YES. SITEMAP_URL = # If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and # QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that # can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help # (.qch) of the generated HTML documentation. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_QHP = NO # If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify # the file name of the resulting .qch file. The path specified is relative to # the HTML output folder. # This tag requires that the tag GENERATE_QHP is set to YES. QCH_FILE = # The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help # Project output. For more information please see Qt Help Project / Namespace # (see: # https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace). # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_NAMESPACE = org.doxygen.Project # The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt # Help Project output. For more information please see Qt Help Project / Virtual # Folders (see: # https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders). # The default value is: doc. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_VIRTUAL_FOLDER = doc # If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom # filter to add. For more information please see Qt Help Project / Custom # Filters (see: # https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_NAME = # The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the # custom filter to add. For more information please see Qt Help Project / Custom # Filters (see: # https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this # project's filter section matches. Qt Help Project / Filter Attributes (see: # https://doc.qt.io/archives/qt-4.8/qthelpproject.html#filter-attributes). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_SECT_FILTER_ATTRS = # The QHG_LOCATION tag can be used to specify the location (absolute path # including file name) of Qt's qhelpgenerator. If non-empty doxygen will try to # run qhelpgenerator on the generated .qhp file. # This tag requires that the tag GENERATE_QHP is set to YES. QHG_LOCATION = # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be # generated, together with the HTML files, they form an Eclipse help plugin. To # install this plugin and make it available under the help contents menu in # Eclipse, the contents of the directory containing the HTML and XML files needs # to be copied into the plugins directory of eclipse. The name of the directory # within the plugins directory should be the same as the ECLIPSE_DOC_ID value. # After copying Eclipse needs to be restarted before the help appears. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_ECLIPSEHELP = NO # A unique identifier for the Eclipse help plugin. When installing the plugin # the directory name containing the HTML and XML files should also have this # name. Each documentation set should have its own identifier. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. ECLIPSE_DOC_ID = org.doxygen.Project # If you want full control over the layout of the generated HTML pages it might # be necessary to disable the index and replace it with your own. The # DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top # of each HTML page. A value of NO enables the index and the value YES disables # it. Since the tabs in the index contain the same information as the navigation # tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. DISABLE_INDEX = NO # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index # structure should be generated to display hierarchical information. If the tag # value is set to YES, a side panel will be generated containing a tree-like # index structure (just like the one that is generated for HTML Help). For this # to work a browser that supports JavaScript, DHTML, CSS and frames is required # (i.e. any modern browser). Windows users are probably better off using the # HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can # further fine tune the look of the index (see "Fine-tuning the output"). As an # example, the default style sheet generated by doxygen has an example that # shows how to put an image at the root of the tree instead of the PROJECT_NAME. # Since the tree basically has the same information as the tab index, you could # consider setting DISABLE_INDEX to YES when enabling this option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_TREEVIEW = NO # When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the # FULL_SIDEBAR option determines if the side bar is limited to only the treeview # area (value NO) or if it should extend to the full height of the window (value # YES). Setting this to YES gives a layout similar to # https://docs.readthedocs.io with more room for contents, but less room for the # project logo, title, and description. If either GENERATE_TREEVIEW or # DISABLE_INDEX is set to NO, this option has no effect. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. FULL_SIDEBAR = NO # The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that # doxygen will group on one line in the generated HTML documentation. # # Note that a value of 0 will completely suppress the enum values from appearing # in the overview section. # Minimum value: 0, maximum value: 20, default value: 4. # This tag requires that the tag GENERATE_HTML is set to YES. ENUM_VALUES_PER_LINE = 4 # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used # to set the initial width (in pixels) of the frame in which the tree is shown. # Minimum value: 0, maximum value: 1500, default value: 250. # This tag requires that the tag GENERATE_HTML is set to YES. TREEVIEW_WIDTH = 250 # If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to # external symbols imported via tag files in a separate window. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. EXT_LINKS_IN_WINDOW = NO # If the OBFUSCATE_EMAILS tag is set to YES, doxygen will obfuscate email # addresses. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. OBFUSCATE_EMAILS = YES # If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the pdf2svg # tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see # https://inkscape.org) to generate formulas as SVG images instead of PNGs for # the HTML output. These images will generally look nicer at scaled resolutions. # Possible values are: png (the default) and svg (looks nicer but requires the # pdf2svg or inkscape tool). # The default value is: png. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FORMULA_FORMAT = png # Use this tag to change the font size of LaTeX formulas included as images in # the HTML documentation. When you change the font size after a successful # doxygen run you need to manually remove any form_*.png images from the HTML # output directory to force them to be regenerated. # Minimum value: 8, maximum value: 50, default value: 10. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_FONTSIZE = 10 # The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands # to create new LaTeX commands to be used in formulas as building blocks. See # the section "Including formulas" for details. FORMULA_MACROFILE = # Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see # https://www.mathjax.org) which uses client side JavaScript for the rendering # instead of using pre-rendered bitmaps. Use this if you do not have LaTeX # installed or if you want to formulas look prettier in the HTML output. When # enabled you may also need to install MathJax separately and configure the path # to it using the MATHJAX_RELPATH option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. USE_MATHJAX = NO # With MATHJAX_VERSION it is possible to specify the MathJax version to be used. # Note that the different versions of MathJax have different requirements with # regards to the different settings, so it is possible that also other MathJax # settings have to be changed when switching between the different MathJax # versions. # Possible values are: MathJax_2 and MathJax_3. # The default value is: MathJax_2. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_VERSION = MathJax_2 # When MathJax is enabled you can set the default output format to be used for # the MathJax output. For more details about the output format see MathJax # version 2 (see: # http://docs.mathjax.org/en/v2.7-latest/output.html) and MathJax version 3 # (see: # http://docs.mathjax.org/en/latest/web/components/output.html). # Possible values are: HTML-CSS (which is slower, but has the best # compatibility. This is the name for Mathjax version 2, for MathJax version 3 # this will be translated into chtml), NativeMML (i.e. MathML. Only supported # for NathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This # is the name for Mathjax version 3, for MathJax version 2 this will be # translated into HTML-CSS) and SVG. # The default value is: HTML-CSS. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_FORMAT = HTML-CSS # When MathJax is enabled you need to specify the location relative to the HTML # output directory using the MATHJAX_RELPATH option. The destination directory # should contain the MathJax.js script. For instance, if the mathjax directory # is located at the same level as the HTML output directory, then # MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax # Content Delivery Network so you can quickly see the result without installing # MathJax. However, it is strongly recommended to install a local copy of # MathJax from https://www.mathjax.org before deployment. The default value is: # - in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2 # - in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3 # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_RELPATH = # The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax # extension names that should be enabled during MathJax rendering. For example # for MathJax version 2 (see # https://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions): # MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols # For example for MathJax version 3 (see # http://docs.mathjax.org/en/latest/input/tex/extensions/index.html): # MATHJAX_EXTENSIONS = ams # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_EXTENSIONS = # The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces # of code that will be used on startup of the MathJax code. See the MathJax site # (see: # http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an # example see the documentation. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_CODEFILE = # When the SEARCHENGINE tag is enabled doxygen will generate a search box for # the HTML output. The underlying search engine uses javascript and DHTML and # should work on any modern browser. Note that when using HTML help # (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) # there is already a search function so this one should typically be disabled. # For large projects the javascript based search engine can be slow, then # enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to # search using the keyboard; to jump to the search box use + S # (what the is depends on the OS and browser, but it is typically # , /