ryanheise
commented
8 months ago My view on this is perhaps not what you expect, but I would be an advocate for having multiple audio plugins, each specialising in certain kinds of audio APIs, rather than having a single plugin that does everything. flutter_sound was very much in the latter category, since it did playback of encoded audio, playing raw streams, recording audio, background audio, etc. The issue is that an app may want to pick and choose only some of these APIs which are relevant for their app, and then to be able to pick and choose their favourite plugin for each of these APIs respectively. When a single plugin does everything, it is difficult to mix and match different plugins achieve interoperability between alternative plugins in the ecosystem.
So I would like to see a separate plugin for playing encoded audio (just_audio), recording, background (audio_service), sound pools, etc. etc. Just as platforms like Android have completely separate APIs for each of these things.
But if you are set on using just_audio for realtime audio, you might be able to get StreamAudioSource to be closer to real time by passing different load control parameters into the constructor to get it to play more immediately without buffering too much beforehand, but you would still need to encode the data since just_audio is designed to play encoded audio.
Riyan-M
Is your feature request related to a problem? Please describe. This is something that flutter_sound supports, but beyond just streaming bytes (and letting the OS handle the playback of the stream via a proxy), for real-time use cases, it's helpful to have an API that supports playback of byte[] samples as they are received (in a VOIP system, audio mixing, real-time audio playback, etc.). Right now, the use of the proxy subjects playback to latency that's imposed by the native audio system (setup, network, buffering, headers, etc.), which can be avoided as both Android and iOS have real-time audio playback capabilities (beyond just playing a URL).
Describe the solution you'd like Unlike StreamingAudioSource which isn't real-time, add an API that takes a linear PCM byte[] with format specifications (channels, sample rate, bit depth) and send that off to the native platform for playback. Playback controls would be limited to controlling the current block only (and any buffered chunks that are yet-to-be played). Probably some control to purge the playback queue would be needed as well.
Describe alternatives you've considered flutter_sound but that package does not seem to be maintained anymore. Depending on licensing restrictions, perhaps some portion of that project's native code can be ported across.