Description
Summary
Currently working with AudioData as a stream is unnecessarily difficult and the experience could be improved
What is the feature request for?
The core library
The Problem
There's 2 issues with using AudioData as a stream in current version of pycord.
Encoding
AudioData objects generated by Sinks do not have the proper .wav or .mp3 encoding (including valid byte prefixes) for the data to be read directly without doing the encoding by hand. Doing the encoding without saving to a file isn't a common use case, and as such it requires the developer to subclass existing audio manipulation libraries (like wav or pydub) to achieve that goal.
Library support
voice_client.start_recording() currently requires a coroutine callback as one of it's arguments. This means you not only have to pass a function even if you don't need one, but the function can't even be a lambda, since it is required that it is a coroutine.
vc.start_recording(
sink,
lambda x, y: x #will error out
)
The Ideal Solution
Encoding
Add a .read(user_id, starting_byte=0, encode=False) method to sinks (or AudioData) which returns encoded data of the underlying AudioData object like a stream would. Make encoding optional and otherwise match the selected sink (like .wav for WaveSink).
Library support
Make the callback argument optional, or at the very least allow for passing an empty lambda as the callback.
The Current Solution
Encoding
It is possible to subclass WaveSink & AudioData to add your own .read() method, and to subclass an audio manipulation library like wav or pydub to encode the audio stream without saving it to a file.
Library support
Unfortunately you can only create a dummy coroutine that does nothing, or pass a lambda and catch the function call in a try catch block.
Additional Context
I've implemented a rough solution over at wmetryka/pycord-voice-interface if you want to look at an example.