NibbleRealm / twang

Library for pure Rust advanced audio synthesis.
https://nibblerealm.com/twang/
Apache License 2.0
125 stars 8 forks source link

What is going on with the examples ? #3

Closed Wicpar closed 3 years ago

Wicpar commented 3 years ago

Hi,

I am trying to use this library, but half of the functions and structs seem to be missing... There is no Fc::new, no Saw, etc... The examples are unusable...

What is going on ?

AldaronLau commented 3 years ago

Hi, I'm actually in the middle of fixing it right now.  Give me like an hour and a half (maybe sooner).  The issue is I changed the API of the fon crate to work with the wavy crate but completely forgot to fix the twang examples.  Not really sure how this escaped me.

Wicpar commented 3 years ago

Oh ok, great, keep me posted, i'll try it later.

AldaronLau commented 3 years ago

@Wicpar The examples should be fixed now.

Wicpar commented 3 years ago

It works now, but performance of the synthesis is abysmal... 126,564,240 ns per iter (only the synth.gen bit, not the setup or audio write) on my xeon E-2176M

I need to encode data frames for ultrasonic communication, so I cannot afford this much overhead...

Thanks for the quick fix nevertheless.

AldaronLau commented 3 years ago

@Wicpar That doesn't seem right. I have not optimized it very much yet, but even on a debug build I can generate 5 seconds of a sawtooth wave, and write it out my SSD in 0.120 seconds. Even including the file I/O, that is 240000 iterations per 120 milliseconds, which is 500 nanoseconds per iteration. My machine is a 10th gen Intel Core i5, but I don't think even large machine differences could cause that huge of a performance difference. Can you double check your measurements?

Wicpar commented 3 years ago

Your numbers are correct, i mean each 5 sec clip generation from your example takes 126ms, which is way too high... The system needs to work on old crappy smartphones...

AldaronLau commented 3 years ago

I guess I don't know much about ultrasonic communication, but as long as you're not generating audio way faster than you play it, I would think the current amount overhead wouldn't be an issue and probably run fine even on my first smart phone (which was very crappy). Although, if you can come up with a way to make it faster, I am definitely accepting pull requests. Good luck to you, though, the algorithm is pretty bare-bones besides just a lot of newtypes.