nRF5340 AUDIO ,AUDIO FRAME DURATION

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Karl Ylvisaker — Tue, 18 Apr 2023 12:05:51 GMT

[quote user="huniu"]1.You are right,I fixed this.Now is not a problem.[/quote]

Great, I am happy to hear that! :)

[quote user="huniu"]2.I still confuse.Can BIS mode suport 44.1K biterate.My hardware only suport 44.1K biterate,So I need LC3 suprot 44.1K,but seems like LC3 not suport 44.1K in project NRF5340 Audio.[/quote]

This is correct - there is unfortunately no support for 44.1 kHz in the nRF5340 Audio reference application as of now.

Best regards,
Karl

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

huniu — Mon, 17 Apr 2023 08:12:03 GMT

1.You are right,I fixed this.Now is not a problem.

2.I still confuse.Can BIS mode suport 44.1K biterate.My hardware only suport 44.1K biterate,So I need LC3 suprot 44.1K,but seems like LC3 not suport 44.1K in project NRF5340 Audio.

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Karl Ylvisaker — Fri, 14 Apr 2023 12:49:01 GMT

1. That is not an accurate way to measure the execution time, since the nRF Connect SDK is build on the Zephyr RTOS, and this process runs as a thread - i.e it may be interrupted so long as it fulfills its real-time constraints. The way you are measuring it indicates that it is blocking, but this is not the case - other tasks and threads can run inbetween, depending on their priority.

You could instead use runtime statistics if you want to know what percent of the CPU is being used by a specific thread, for instance.

2. Thank you for clarifying.

Best regards,
Karl

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

huniu — Fri, 14 Apr 2023 12:22:58 GMT

static void encoder_thread(void *arg1, void *arg2, void *arg3)
{
	int ret;
	uint32_t blocks_alloced_num;
	uint32_t blocks_locked_num;

	int debug_trans_count = 0;
	size_t encoded_data_size = 0;

	void *tmp_pcm_raw_data[CONFIG_FIFO_FRAME_SPLIT_NUM];
	char pcm_raw_data[FRAME_SIZE_BYTES];

	static uint8_t *encoded_data;
	static size_t pcm_block_size;
	static uint32_t test_tone_finite_pos;

	while (1) {
		/* Get PCM data from I2S */
		/* Since one audio frame is divided into a number of
		 * blocks, we need to fetch the pointers to all of these
		 * blocks before copying it to a continuous area of memory
		 * before sending it to the encoder
		 */
		for (int i = 0; i < CONFIG_FIFO_FRAME_SPLIT_NUM; i++) {
			ret = data_fifo_pointer_last_filled_get(&fifo_rx, &tmp_pcm_raw_data[i],
								&pcm_block_size, K_FOREVER);
			ERR_CHK(ret);
			memcpy(pcm_raw_data + (i * BLOCK_SIZE_BYTES), tmp_pcm_raw_data[i],
			       pcm_block_size);

			data_fifo_block_free(&fifo_rx, &tmp_pcm_raw_data[i]);
		}
		IO_invert();
		if (sw_codec_cfg.encoder.enabled) {
			if (test_tone_size) {
				/* Test tone takes over audio stream */
				uint32_t num_bytes;
				char tmp[FRAME_SIZE_BYTES / 2];

				ret = contin_array_create(tmp, FRAME_SIZE_BYTES / 2, test_tone_buf,
							  test_tone_size, &test_tone_finite_pos);
				ERR_CHK(ret);

				ret = pscm_copy_pad(tmp, FRAME_SIZE_BYTES / 2,
						    CONFIG_AUDIO_BIT_DEPTH_BITS, pcm_raw_data,
						    &num_bytes);
				ERR_CHK(ret);
			}

			ret = sw_codec_encode(pcm_raw_data, FRAME_SIZE_BYTES, &encoded_data,
					      &encoded_data_size);

			ERR_CHK_MSG(ret, "Encode failed");
		}

		/* Print block usage */
		if (debug_trans_count == DEBUG_INTERVAL_NUM) {
			ret = data_fifo_num_used_get(&fifo_rx, &blocks_alloced_num,
						     &blocks_locked_num);
			ERR_CHK(ret);
			LOG_DBG(COLOR_CYAN "RX alloced: %d, locked: %d" COLOR_RESET,
				blocks_alloced_num, blocks_locked_num);
			debug_trans_count = 0;
		} else {
			debug_trans_count++;
		}

		if (sw_codec_cfg.encoder.enabled) {
			/* Send encoded data over IPM */
			streamctrl_encoded_data_send(encoded_data, encoded_data_size);
		}
		IO_invert();
		STACK_USAGE_PRINT("encoder_thread", &encoder_thread_data);
	}
}

line 33 and line 72.IO invert,take about 6ms

2.I mean hardware codec.

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Karl Ylvisaker — Fri, 14 Apr 2023 11:52:11 GMT

Thank you for elaborating.

[quote user="huniu"]2.LC3 encode need 6ms,I invert IO in "encoder_thread",it takes about 6ms.Then I have no time do my own work,such as another encode.[/quote]

I am not sure that I understand what you mean when you say 'I invert IO in 'encoder_thread'', could you clarify?
The rule of thumb is that using the provided LC3 implementation it will require roughly 30% of the CPU time to encode a 96 kbps stream (at 48 kHz sampling), and roughly 15% to decode the same stream. So, if you are only encoding 1 or 2 streams you should still have ample time to do your own application work.

[quote user="huniu"]3.My codec only suport 44.1K,So I need 44.1K.[/quote]

To be specific, is this a hardware codec you are referring to, or a software codec (like the LC3, or an equivalent)?
In case of the latter please note that you must have the LC3 as the primary codec on your device if you intend to qualify as a LE Audio product (you are allowed to have proprietary secondary codecs in addition to the LC3, of course).

Best regards,
Karl

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

huniu — Thu, 13 Apr 2023 02:34:39 GMT

1.Yes,My audio from uart.

2.LC3 encode need 6ms,I invert IO in "encoder_thread",it takes about 6ms.Then I have no time do my own work,such as another encode.

3.My codec only suport 44.1K,So I need 44.1K.

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Karl Ylvisaker — Wed, 12 Apr 2023 11:20:02 GMT

Hello,

[quote user="huniu"]Can I low down the i2s bitrate to 44.1K?[/quote]

We currently do not have support for 44.1 kHz sampling frequency, no.
Is there a particular reason why you would like to use 44.1kHz instead of 48?

Please also see the question from my colleague Øyvind about elaborating on your requirements and constraints so that we may better be able to help you.

Best regards,
Karl

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

huniu — Thu, 06 Apr 2023 03:06:10 GMT

Can I low down the i2s bitrate to 44.1K?

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Øyvind — Tue, 04 Apr 2023 06:56:26 GMT

Hello again,

Here is the initial answers from our audio team:

No, the audio frame duration is highly related with

The synchronization and drift compensation mechanism in audio_datapath module

The frame size setting for LC3 ENC/DEC

I2S sampling number

And it is very strange that the customer needs 5~6ms for encoding the data.

There way to reduce the LC3 encoded time is to low down the bitrate.

But it is still hard to understand what would the customer want to achieve, seems the audio is not from I2S but from UART.

In addition: The audio frame duration is set by the LE Audio standards. It is not user adjustable. (It is possible to choose other codecs and other frame sizes, but that is a proprietary extension and out side the specs. For a qualifiable solution, the standardized frame size must be supported.)

Would it be possible for you to share more details of what you are trying to achieve? Our audio team would like to assist, however, more details are needed.

Kind regards,
Øyvind

RE: nRF5340 AUDIO ,AUDIO FRAME DURATION

Øyvind — Fri, 31 Mar 2023 13:30:47 GMT

Hello, I have forwarded the question to our audio team and will get back to you on Tuesday.

Note that due to Easter holidays we will have less staffing in the coming week, and some delays in answers must be expected.

Kind regards,
Øyvind