Data shifting I2S

RE: Data shifting I2S

Edvin — Wed, 27 Nov 2024 14:32:13 GMT

There are some special components that are placed on the nRF53 Audio DK that are not present on the nRF54L15 DK (also not present on the nRF5340 DK). Also the sample application is not ported to the nRF54, so the short answer is no. Not at this point in time.

I think there is planned to support it in the future, but I don't know when that will come. Also, the lack of the AudioPLL on the nRF54L may cause the I2S Sampling clock to drift, which may or may not be an issue in your case, depending on the application (particularly the length of your samples).

Best regards,

Edvin

RE: Data shifting I2S

Kashyap23 — Fri, 22 Nov 2024 05:11:24 GMT

Hi Edvin ,we have received samples of nrf54L15 series evm ,will this audio sample with lc3 codec woks here also?

RE: Data shifting I2S

Edvin — Thu, 14 Nov 2024 15:02:18 GMT

I suggest that you study the sample application, NCS\nrf\applications\nrf5340_audio, as this is a complex subject. Also see the documentation for this application.

It is not standard BLE, but BLE Audio, which is fairly new. The LC3 codec is automatically used, unless you specify something else.

Regarding the delay, I don't know any way to do this more efficiently, if it is a possibility to use another sample bit width than 18, or a different microphone.

Best regards,

Edvin

RE: Data shifting I2S

Kashyap23 — Thu, 14 Nov 2024 09:30:17 GMT

Thanks for that Edvin,this definitely helps and works for me but I have tried with i2s_buff_r/w function which solved my issue in shifting and writing to i2s_buff_write with a minimal delay I can able to listen audio in Amplifier .Can this delay be reduced ?if yes ,suggest me the way and now I need to transfer shifted data over BLE.In order to achieve that ,guide me the way.My sampling rate is 16000.I saw the audio sample is incorporated with LC3 codec but not understanding to achieve blewith my audio data.

Thanks

Kashyap

RE: Data shifting I2S

Edvin — Wed, 13 Nov 2024 14:29:09 GMT

These pointer bit-handling is always a bit tricky. Particularly with void * buffers. I added this to one of our samples (I used the central_uart from ncs\nrf\samples\bluetooth\central_uart, since I recently used it for something else). I added these functions, and called it from the start of main:

void print_blob(int *int_blob, int16_t num_elements)
{
    for (int i=0; i<num_elements; i++) {
        LOG_INF("blob [%d] = 0x%08x", i, int_blob[i]);
    }
}

void process_blob(void *blob, int16_t num_elements)
{
    uint32_t *int_blob = blob;
    for (int i=0; i<num_elements;i++){
        int_blob[i] = int_blob[i]>>16;
    }
}

void test_function(void)
{
    LOG_INF("test_blob");
    void *blob;
    blob = k_malloc(3*sizeof(uint32_t));
    if (blob) {
        uint32_t *int_blob = (uint32_t*)blob;
        LOG_INF("k_malloc success");
        int_blob[0] = 0x11111111;
        int_blob[1] = 0xFFFFFFFF;
        int_blob[2] = 0x0000FFFF;
        LOG_INF("pre processing********");
        print_blob(blob, 3);
        process_blob(blob,3);
        LOG_INF("post processing*******");
        print_blob(blob, 3);

        //blob = int_blob;
        LOG_INF("blob = %p", blob);
        LOG_INF("int_blob = %p", int_blob);
    } 
    else {
        LOG_ERR("k_malloc fail");
    }
    
}

int main(void)
{
    test_function();

Note that I casted the pointer to a uint32_t pointer before doing modifications to it. As long as it is a pointer that is set to the same address, the content of my "blob" void pointer is also changed.

This produced the following log:

[00:00:00.000,640] <inf> central_uart: test_blob
[00:00:00.000,701] <inf> central_uart: k_malloc success
[00:00:00.000,701] <inf> central_uart: pre processing********
[00:00:00.000,732] <inf> central_uart: blob [0] = 0x11111111
[00:00:00.000,732] <inf> central_uart: blob [1] = 0xffffffff
[00:00:00.000,762] <inf> central_uart: blob [2] = 0x0000ffff
[00:00:00.000,762] <inf> central_uart: post processing*******
[00:00:00.000,793] <inf> central_uart: blob [0] = 0x00001111
[00:00:00.000,793] <inf> central_uart: blob [1] = 0x0000ffff
[00:00:00.000,793] <inf> central_uart: blob [2] = 0x00000000
[00:00:00.000,823] <inf> central_uart: blob = 0x20008f48
[00:00:00.000,915] <wrn> cbprintf_package: (unsigned) char * used for %p argument. It's recommended to cast it to void * because it may cause misbehavior in certain configurations. String:"int_blob = %p" argument:0
[00:00:00.000,915] <inf> central_uart: int_blob = 0x20008f48

Try something similar for your processing function.

Best regards,

Edvin

RE: Data shifting I2S

Kashyap23 — Tue, 12 Nov 2024 06:39:48 GMT

Data will be in 18 MSB,so I am shifting 16 bits to get 16 bit of each mic sample

[quote userid="26071" url="~/f/nordic-q-a/116199/data-shifting-i2s/509905"] Does it work? What do you see?[/quote]

Data is not shifting .How can I achieve and pass to amplifier of only one mic data of 16000 samples(I will use second mic data for ANC )So I need output of only one mic .How can I do that

RE: Data shifting I2S

Edvin — Mon, 11 Nov 2024 13:48:49 GMT

You say that your bitlength is 18 bit. What does it look like when it enters the application?

I see that you are doing some bit shifting in your handler. Does it work? What do you see? And in each of your samples (32bit, I guess). Where is the data? Is it occupying the 18 least significant bits (lower bits), or the 18 most significant bits(upper bits)?

Best regards,

Edvin

RE: Data shifting I2S

Kashyap23 — Mon, 11 Nov 2024 09:44:21 GMT

In addition that I want to know that can we use i2s_read for getting data and loading into buffer and doing shifting then use i2s_buf_write for sending data out?