You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the new feature you'd like
I'm trying to use this awesome software to monitor a remote audio feed in as close to realtime as possible. It's doing good but would like to know if there's a compression available that doesn't introduce crazy delay or kill the CPU but still reduce some of the fat WAV bits going down the pipe.
Describe the reason why you want to add the feature
I need this feature because I stream audio across the internet to monitor inputs and such. That's not in the same local network, across different ISPs.
Describe how to implement the feature if you can
ffmpeg seems to encode and decode mp3 and m4a at 30x or so, maybe that's enough performance to not introduce a huge delay. I also don't mean you should go the mp3/m4a route, it's just an example.
The text was updated successfully, but these errors were encountered:
Actually, in v0.0.1, Audio Share use TCP to transfer the audio data. Because it has a high latency, so I change it to UDP. In the feature, I'll add it back to provide a alternative way to tranfer the audio data. TCP is stable to tranfer data arcoss the Internet. The compression of audio data can decrease the bandwidth and the lantency.
Describe the new feature you'd like
I'm trying to use this awesome software to monitor a remote audio feed in as close to realtime as possible. It's doing good but would like to know if there's a compression available that doesn't introduce crazy delay or kill the CPU but still reduce some of the fat WAV bits going down the pipe.
Describe the reason why you want to add the feature
I need this feature because I stream audio across the internet to monitor inputs and such. That's not in the same local network, across different ISPs.
Describe how to implement the feature if you can
ffmpeg seems to encode and decode mp3 and m4a at 30x or so, maybe that's enough performance to not introduce a huge delay. I also don't mean you should go the mp3/m4a route, it's just an example.
The text was updated successfully, but these errors were encountered: