Open Larpoux opened 3 years ago
τ 7.5.0 implements this new verb.
This new example can be compared to the old loop example.
startPlayerFromMic()
directely links the microphone to the headset inside the OS, without any processing by τ
The improvement is really good. The delay between what is recorded and what is played is much better.
The link beetween the microphone and the headset is done inside τ-core. The messaging channels between Java and Dart is not involved. The audio data are just transfered from the recording-thread to the player thread.
This is a great disappointment : the performances are marginally improved. This means that implementing data transfert from/to Dart with FFI will not benefit from using FFI.
We must improve the latency
problem under Andoid.
For my project the latency in Android is the most blocking issue (making it useless for now, sadly). Do you have any idea of the possible reason?
For me it is the same, does flutter_sound use Oboe in Android to speed up the latency (also checkout following projects: https://www.youtube.com/watch?v=X8JD8hHkBMct=23m&t=23m, https://github.com/audiooffler/JucyFluttering)?
Thank you for your feedback @pffelix . I do not know Oboe I really want something usable with Audio Streams. The latency is a big problem that I want to solve soon (in the 9.0 fork). I have big ideas for future development, but it will never be possible if too much latency
this sample here describes how you can achieve minimal latency for audio passthrough on Android with Oboe: https://github.com/google/oboe/tree/main/samples/LiveEffect
Thanks 👍
This issue is stale because it has been open 90 days with no activity. Leave a comment or this will be closed in 7 days.
Several τ users need to play on the headset what is recorded by the microphone, in quasi-real-time.
I am convinced that implementing audio-graph will be the general solution and will be very elegant.
Unfortunately, I worry that I will have to leave the τ project before having implemented this terrific feature. (another project is waiting for me).
So, I think that we can implement a new simple verb
startPlayerFromMic()
before the great global solution. And use FFI instead of the Flutter channels if the App wants to be in cut-mode during the process instead of pass-threw.