Welcome to zero-delay-audio-codec Discussions!

[suaefar]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[Solomute]

Hi - You mention in your Readme that you encountered some objections to the purpose of developing a zero-latency audio codec. This is because most people thinking about audio codec development are doing so in the context of VoIP where the latency of the internet dominates over codec latency.

The reason to develop a zero-latency audio codec is in the hands of every singer on a stage. Air-to-air latency of digital audio systems is incredibly critical in music production, where latencies as low as 5ms can noticeably affect musical timing perceived by musicians. With analog-to-analog latency in digital audio mixing consoles being in the ballpark of 2ms or so, your wireless links from microphone to console, and console to in-ear monitoring, need to be on the order of 1ms or so. This includes A/D and D/A latencies, which get multiplied by two if your wireless equipment doesn't speak the same digital protocol as your mixing console (very common, unfortunately).

Wireless microphones can't simply use PCM because their RF bandwidth is limited by regulation, typically to about 200khz. You also need to be able to tolerate RF dropouts and interference. This means you're looking for a codec that can push zero-latency, transparent CD-quality audio at about 192kbps after error correction, with no bit reservoir because your RF channel has a hard bandwidth limit.

[suaefar]

Thank you very much for your comment!

Yes, that sounds like an interesting possible application.
The presented bitrates in the Readme are for stereo signals (no joint coding).
Hence 192kbit/s for single channel streams are perfectly in the scope.
I think the LPC-based prediction should work reasonably well with voices.

However, some reservoir/buffer is always needed.
Here, the symbols don't have a fixed length so the buffer needs to be as long as the worst case encoded sample.
In the worst case this should be about 32 bit, maybe 48 bit (which would equal 0.25 ms at 192kbit/s), but one could reduce the maximum (at the cost of the accuracy on that sample).

[Solomute]

How is the computational complexity of encoding? Can you see it being possible to do in real time on a battery powered microcontroller drawing 1 watt or so?

[suaefar]

Yes, that should be possible.
The demanding parts of the encoder are the LPC (levinson-durban) and the fourth order gammatone filterbank which has to be implemented in the time-domain. The rest should be mainly simple operations and a lookuptable for the symbols.

The encoding artifacts are almost analog: its quantization noise.

An implementation in C should run on a Raspberry PI 3B in real-time. This is more than 1W, but with some optimization on a suitable platform I bet much less is possible.