zephyrproject-rtos / liblc3codec Goto Github PK

Hi @aescolar ,

There is a LC3 sample binary file on BluetoothSIG working group which can be used to verify the correctness.
I found that inputs of the CLI tool are different from this API, this made me hard to verify it.
In this library, the encoder and decoder should pass byte_count argument into run method. That's mean compress a frame duration data into byte_count size. But the CLI tool only can be provided a target bit rate, and it would try to reach the bit rate.
Because of this difference, I don't know how to use that tool decode the data encoded by this API.
Would you have any idea about it?

I found the branch name "sneak_peek". Where can I found the source of it?

Regards

When encoding a 400Hz sinewave at 16kHz sample rate it was observed that the codec was clipping the sine, hence volume reduced by 10% as this removed the clipping. But even with this reduction other codecs will discard the data due to invalid content in the frame.

A capture was shared with Ellisys for analysis, and their response were:

In the very first SDU of that trace, the first 40 bytes can be properly decoded with the given parameters, namely a 10ms frame duration and 16kHz sampling frequency.
For the second part, the decoder detects an impossible value in the side band information.
The number of spectral lines for this configuration is 160 (in this case identical to the number of samples per frame). That maps to a compressed "last non zeroed index" field length of 7 bits. Those 7 bits have the compressed value 97, that expands to 196. Since the "last non zeroed index" cannot be higher than the number of spectral lines, that sideband information is considered invalid and the frame not accepted.
To avoid false positives, the LC3 auto-detection requires all frames in an SDU to be decodable, which is thus not the case in this trace

The trace was using the current default settings in the unicast sample application. 32kbps, 16kHz, 10ms frames, volume: (INT16_MAX - 3000), 400Hz sine.

A volume of ~75% works around this issue (INT32_MAX - 8000). Also at 48kHz the issue do not seem to exist - even at full volume (+/-INT16_MAX).

UPDATE 2. of May 2022:
PLEASE NOTE:
When looking at this, please note that the issue occurs for HIGH volume. Above a certain gain level the LC3 encoder will start to produce invalid frames. Also please note that the nature of LC3 will introduce a "ramp-up" period where the output amplitude is not 100% even though you supply a 100% gain input signal. Hence please ensure you skip the first few frames for the analysis.
Also please note that several different combinations of frames/SDU were tested, and the issue disappears if gain is reduced - hence this issue is not related to how data is packed in to the SDU.

It will be better to port this codebase as external project (https://docs.zephyrproject.org/latest/develop/modules.html)
The root codebase has landed to github (https://github.com/google/liblc3)
The last version includes many speed improvements, especially for ARM Cortex M series.

Hello, how to call the LC3 decoder in an android project? Thank you so much

When testing audio broadcast, we got a larger number of lost packets and tried to enable the PLC in this (Android's) LC3 codec. However, it's basically not working.

Did anybody try it's PLC yet?

Given that I had no idea where to file an issue with Android, I figured this could be a reasonable place for discussion, too.

I've created a minimal test application that encodes a sine wave and then drops every 20th packet, decodes it and stores it into a wav file.

The wav file is attached: https://user-images.githubusercontent.com/652934/179232913-e903eae1-3052-4a45-b407-fe3ddb349eb0.mp4

and the the test code is here: https://github.com/bluekitchen/liblc3codec/tree/plc-test

(If you want to add the test code here, please say so and let me know what I need to change from an licensing point of view).

Cheers
Matthias