mrdimas / hrtf Goto Github PK
View Code? Open in Web Editor NEWHead-Related Transfer Function (HRTF) audio signal processor.
License: MIT License
hrtf's People
Contributors
Stargazers
Watchers
hrtf's Issues
API coordinate system
I'm currently working on wrapping hrtf crate in the GStreamer plugin. I was wondering if you could help me to clarify some of the API constraints?
Those are the questions:
- do coordinates passed to the processor have units? meters for instance?
- if not, do they have to be normalized so they are in the range [-1.0, 1.0]?
- is the coordinate system left or right handed?
- what would be an example of static object positions that correspond to 5.1 speaker layout with the listener at
0.0.0? E.g. would that work for front left/right speakers:
FrontLeft => Vec3 {
x: -1.45,
y: 0.0,
z: 2.5,
},
FrontRight => Vec3 {
x: 1.45,
y: 0.0,
z: 2.5,
},
Thank you for all amazing work
Panic for low sample rate
The following snippet panics with
Input FFT buffer must be a multiple of FFT length. Expected multiple of 639, got len = 702
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_sample_rate() {
let resource = File::open("resources/IRC_1003_C.bin").unwrap(); // IRCAM listen db
let sphere = HrirSphere::new(resource, 24000).unwrap(); // low sample rate
let _proc = HrtfProcessor::new(sphere, 1, 128);
}
}
You could argue 24k is too low of a sample rate anyway. This could maybe be encoded into a new error variant of HrtfError?
But there also may be an underlying issue regarding the length of the HRIR length vs the sample rate. I have not looked into this myself.
Full stacktrace:
0: rust_begin_unwind
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
1: core::panicking::panic_fmt
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:270:5
4: rustfft::common::fft_error_inplace
at /Users/otto/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustfft-6.1.0/src/common.rs:25:5
5: <rustfft::algorithm::mixed_radix::MixedRadix<T> as rustfft::Fft<T>>::process_with_scratch
at /Users/otto/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustfft-6.1.0/src/common.rs:241:21
6: rustfft::Fft::process
at /Users/otto/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustfft-6.1.0/src/lib.rs:188:9
7: hrtf::make_hrtf
at ./src/lib.rs:256:5
8: hrtf::HrtfSphere::new::{{closure}}
at ./src/lib.rs:636:33
9: core::iter::adapters::map::map_try_fold::{{closure}}
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/iter/adapters/map.rs:91:28
10: core::iter::traits::iterator::Iterator::try_fold
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/iter/traits/iterator.rs:2461:21
11: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/iter/adapters/map.rs:117:9
12: <I as alloc::vec::in_place_collect::SpecInPlaceCollect<T,I>>::collect_in_place
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/alloc/src/vec/in_place_collect.rs:258:13
13: alloc::vec::in_place_collect::<impl alloc::vec::spec_from_iter::SpecFromIter<T,I> for alloc::vec::Vec<T>>::from_iter
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/alloc/src/vec/in_place_collect.rs:182:28
14: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/alloc/src/vec/mod.rs:2749:9
15: core::iter::traits::iterator::Iterator::collect
at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/iter/traits/iterator.rs:2053:9
16: hrtf::HrtfSphere::new
at ./src/lib.rs:632:22
17: hrtf::HrtfProcessor::new
at ./src/lib.rs:871:27
18: hrtf::tests::test_sample_rate
at ./src/lib.rs:1022:21
19: hrtf::tests::test_sample_rate::{{closure}}
at ./src/lib.rs:1019:27
Optimize HrtfSphere::sample_bilinear
When using current HRTF renderer with IRCAM spheres in a system with optimized RustFFT implementation (right now an AVX/SSE implementation and in the nearest future Neon implementation ejmahler/RustFFT#78) most of the time in HrtfProcessor::process_samples is spent in hrtf_sphere.sample_bilinear (see attached profile: 56% percent is spent in sample_bilinear, half of time is spent searching for the face and the second h
alf is spent computing left_hrtf and right_hrtf. I've moved the computation of left_hrtf/right_hrtf to a separate inline(never) method in order to be able to see the performance impact).
There are two problems with process_samples:
- Compiler cannot optimize computing
left_hrtf/right_hrtfdue to values being pushed instead of assigned. I've tried a few variants in Godbolt: https://rust.godbolt.org/z/jvb4be6P6 and the only way to get proper vectorization is to pre-resize the array (the resize is replaced with memset) and either use iterators+zip or useget_unchecked_mut. I think iterators+zip is by far a cleaner solution. - Too much time is spent searching for the face which the ray intersects. I've experimented with two solutions. The first is a bit complicated: partition the space with places which pass through each edge of each face and origin (0, 0, 0). This partitioning uniquely identifies a matching face. The additions amount to ~150 lines of code (without tests which, if required, would take another 100-200 lines).
The second one is a quick-and-dirty prototype: split space in 8 octets with center in (0, 0, 0), assign all faces to octets (some faces end up in multiple octets) and thus reduce the search space. This is a short algorithms (~80 lines) but not as efficient as the first method. It can however be easily improved by splittiing the space into more partitions. 
I've implemented both algorithms, you can see the proposed changes here https://github.com/OlegOAndreev/hrtf/commit/415d1af6dd80bbceb464f7615960c9fd87bcc12e
how to use with `.mhr` hrtf files?
hi,
the file format OpenAL-Soft uses is .mhr, but this crate uses a different file.
Can it be used with OpenAL-Soft's .mhr files?
How do I convert for this?
https://github.com/kcat/openal-soft/blob/master/core/hrtf.cpp#L94
https://github.com/kcat/openal-soft/blob/master/core/hrtf.cpp#L508
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.