Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Opus implementation with BLE (SDK 14.2)

Hi,

I'm currently working on an application that collects audio data and sends it to a central device via BLE. Since audio compression has great potential to reduce power consumption, I would like to implement opus (libopus 1.2.1) on the nRF DK 52 (nRF52832). I have a couple of questions regarding that.

After downloading libopus 1.2.1 I'm left with a folder structure, including different makefiles, sourcefiles, etc.

I have some questions regarding the actual implementation into Segger Embedded Studio.

1. Is there example code available for an implementation of Opus on a Nordic chip (using both BLE and opus)? (Smart Remote apparently, but I cannot find any example code)

2. What is a normal way to go about such an implementation? Should I precompile the library and then add it to the Nordic libraries? or can I add the whole folder structure to the Segger IDE and compile it in there?

3. If I'm not mistaken I have a separate makefile for Opus either way. Do I need to merge the makefiles from the BLE Nordic example and Opus or how can I go about this?

4. Very general question, what's the relation between the sdk_config file and the makefile?

By now it's probably clear that I do not have much experience in coding for embedded systems. Just tell me if you need more details or clarifications on some things.

Thanks for the help!

Parents
  • Hi,

    1) Unfortunately, you would need to buy a smart remote to be able to download the source code. Other than the smart remote, I have not found any other example code for Opus on a Nordic chip.

    2) I am slightly unsure about this. My guess is that both would work, but I would add the necessary files to the Segger IDE & compile from there.

    3) From my understanding, the whole idea of make files is to keep the source file(s) up to date. It seems it is good practice to have one makefile in each directory that keeps the components inside that directory up to date. So in your case, if you have multiple directories, you might want to have one makefile per directory & have a top level make file (see link).

    4) I have explained briefly what the makefile does in 3. See this link for more details. The sdk_config file essentially changes the static settings of an application built on top of the nrf5 sdk (see link).

    If I were you, I would take a look at the Thingy FW, as the Thingy:52 device does audio streaming from a smartphone to the Thingy:52 device & vice versa. It uses different audio codecs than OPUS.

    Kind Regards,

    Bjørn Kvaale

Reply
  • Hi,

    1) Unfortunately, you would need to buy a smart remote to be able to download the source code. Other than the smart remote, I have not found any other example code for Opus on a Nordic chip.

    2) I am slightly unsure about this. My guess is that both would work, but I would add the necessary files to the Segger IDE & compile from there.

    3) From my understanding, the whole idea of make files is to keep the source file(s) up to date. It seems it is good practice to have one makefile in each directory that keeps the components inside that directory up to date. So in your case, if you have multiple directories, you might want to have one makefile per directory & have a top level make file (see link).

    4) I have explained briefly what the makefile does in 3. See this link for more details. The sdk_config file essentially changes the static settings of an application built on top of the nrf5 sdk (see link).

    If I were you, I would take a look at the Thingy FW, as the Thingy:52 device does audio streaming from a smartphone to the Thingy:52 device & vice versa. It uses different audio codecs than OPUS.

    Kind Regards,

    Bjørn Kvaale

Children
  • Hi Bjorn

    Thanks for your answer.

    but I would add the necessary files to the Segger IDE & compile from there.

    What exactly do you mean by that? Maybe I'm still not clear on the definition of a library. Do I not need to make opus into a library before using it? How else is opus going to know on which platform it is running?

    Sorry for all the questions, by now I'm just very confused on the relation between operating systems, compilers and makefiles.

    Best,

    Nick

  • Hi Nick,

    A library is essentially a group of functions & definitions that another program has access to & can use (see link). If you take a look at the Blinky example from SDK14.2, you can see the nRF_Libraries folder with contains the app_button.c file. Along with the c file, there is also the app_button.h header file. These two files are part of the button handling library, which allows users to use the buttons to enable some kind of functionality. The .c file contains the function implementation, while the .h file enables an interface (a way for other files to use the functions inside the .c file). By including #include "app_button.h" inside the main.c file, it is possible for the main file to call functions inside the button library.

    So I would consider making a new folder in SES for example& placing all of the OPUS files in there. You can then use the functions inside the OPUS files by for example having a header file for each function & including the header files in the main.c file. 

    Hope that helps!

    Bjørn

Related