This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

For Opus applications, is an Audio DAC chip required?

Hi, guys. I'm trying to work with Opus applications using PCA10056 v1.0. In order to play Opus fils using the nRF52840,

do I need audio DAC + audio amplifier to create sound on a 3.5mm headphone jack or 1W 8 Ohm speakers?

For instance, adding TI's TLV320DAC3101 (32-bit Low-Power Stereo Audio DAC With Stereo Class-D Speaker Amplifier) is mandatory for playing Opus files?

Or using nRF52840's PDM (Pulse density modulation interface) / PCM will do the job so that I only need the audio amplifier?

  • Thanks. 2 last things before closing this.

    The output from opus is PCM format, either floating point or integer, based on which decode function you use.

    This sounds like CELT (Constrained Energy Lapped Transform) vs SILK vs hybrid problem.

    - Since I'm a beginner, choosing a hybrid method seems tough. Most Opus file I have inside the SD card has a length of 30 seconds max, which is mostly speeches (saying go right, turn left on NY street, etc).

    If I pick the priority of small size as possible, which algorithm should I choose; CELT / SILK?

    - CELT vs SILK vs hybrid;

    considering the algorithm I choose, do you mean I have to use a different decoding function?

    Also, these algorithms create different output; floating point / integer?

  • I would recommend that you check out the presentation and slides on the bottom of the Opus page. It seems that SILK would be the best choice for your application.

    Matthew K said:
    considering the algorithm I choose, do you mean I have to use a different decoding function?

    No, as mentioned in this thread:

    2. The Opus decoder does not need additional information to know which algorithm was used to encode the current frame. In the original Opus code (https://opus-codec.org/) there is a function opus_packet_get_mode() which checks if the frame was encoded with CELT or SILK. 

    Matthew K said:
    Also, these algorithms create different output; floating point / integer?

    The algorithms should provide the same output, but the code base can produce both a fixed-point and a floating-point output. This is from their FAQ:

    "If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using --enable-fixed-point or defining FIXED_POINT in the build system."

Related