SuperpoweredDecoder decodeAudio Blocks Indefinitely For Some Sources

[pmarino]

Superpowered version: 2.6.7

Describe the bug
When loading some sources into SuperpoweredDecoder, decodeAudio will block indefinitely. I am able to reproduce the issue on numerous Android devices as well as macOS and Linux environments.

I’ve attached a 32KHz / Mono .m4a which exhibits this issue in some of the latest Superpowered samples — the audio was directly exported from the Google Pixel Recorder app.

Steps to Reproduce

1. Download the following source: example_recording.m4a.zip
2. Replace the test.m4a source in the root of the Examples_Linux directory with the source above
3. Build the Linux examples with the source above
4. Run offline1, offline2 and offline3 examples

Expected behavior

1. The Superpowered Linux examples should finish processing or log an error if the file can’t be opened
2. If there is an issue decoding, SuperpoweredDecoder should return an error code

Actual behavior

1. decodeAudio blocks indefinitely and maxes out CPU usage
   

   Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/Examples_Linux/src/offline1.cpp

   Line 45 in c4c3daf

   int framesDecoded = decoder->decodeAudio(intBuffer, decoder->getFramesPerChunk());

Device information
As noted above, I have been able to reproduce this issue on numerous Android devices and on macOS & Linux. I’ve attached device information for the Linux device that was used for testing the samples in this repository.

• OS: Ubuntu 22.04.4 LTS (6.5.0-26-generic x86_64)
• CPU: Intel Core i5-4570 CPU @ 3.20GHz

Additional context
Here is the output from afinfo for the attached source exhibiting the issue:
example_recording.m4a.zip

File:           example_recording.m4a
File type ID:   mp4f
Num Tracks:     1
----
Data format:     1 ch,  32000 Hz, aac  (0x00000000) 0 bits/channel, 0 bytes/packet, 1024 frames/packet, 0 bytes/frame
                no channel layout.
estimated duration: 59.358000 sec
audio bytes: 356835
audio packets: 1857
bit rate: 48039 bits per second
packet size upper bound: 285
maximum packet size: 285
audio data file offset: 15816
optimized
audio 1899456 valid frames + 2112 priming + 0 remainder = 1901568
format list:
[ 0] format:	  1 ch,  32000 Hz, aac  (0x00000000) 0 bits/channel, 0 bytes/packet, 1024 frames/packet, 0 bytes/frame
Channel layout: Mono

The attached source plays as expected in various other players across iOS, Android and macOS, etc.

[ivannador]

Hey @pmarino,

I can confirm that the issue can be reproduced. The decoder runs into an infinite loop while decoding this file.

Please stay tuned while we further investigate the issue.

[pmarino]

Hi @ivannador,

Thank you for looking into this issue. I noticed in the v2.6.8 release notes that there was a potential fix for the AAC decoding issue. However, after re-testing the affected source with the steps outlined above using v2.6.8, the issue still persists.

[tehsven]

@ivannador Any update on this? We are experiencing a higher than normal ANR rate in our mobile app due to this bug.

[ivannador]

Hey @tehsven

We are looking into the issue, stay tuned.

[gaborszanto]

This file has some strange Huffman encoding that is not supported by our decoder. This file is not AAC-LC or HE-AAC, but some other variant.

[pmarino]

Thanks for the follow-up, @gaborszanto !

Interesting — when running ffprobe and mp4info on the source, the output certainly alludes to AAC-LC.

From ffprobe:
ffprobe_output.txt

From mp4info:
mp4info_output.txt

[gaborszanto]

I see this file has four tracks. Then maybe Superpowered is confused with those. Can you make it to include a single track?

[pmarino]

@gaborszanto , if we use ffmpeg to extract only the audio track, the Decoder works as expected; however, I’m not sure if there is any correlation between the additional processing, since the file might be re-encoded.

ffmpeg -i example_recording.m4a -map 0:a:0 -c copy example_recording_single_track_audio.m4a

example_recording_single_track_audio.m4a.zip

Output #0, ipod, to 'example_recording_single_track_audio.m4a':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    com.android.version: 14
    encoder         : Lavf61.1.100
  Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 32000 Hz, mono, fltp, 48 kb/s (default)
      Metadata:
        creation_time   : 2024-05-02T20:18:47.000000Z
        handler_name    : Soun
        vendor_id       : [0][0][0][0]
Press [q] to stop, [?] for help
[out#0/ipod @ 0x600002f1c000] video:0KiB audio:348KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 2.302184%
size=     356KiB time=00:00:59.42 bitrate=  49.1kbits/s speed=2.34e+04x    

As noted earlier in this thread, the original example_recording.m4a was a direct export from the Google / Android Pixel Recorder app.

[wacheski]

Hi @ivannador, @gaborszanto & @pmarino

The Google Recorder available on Google Play for Android devices with transcription and editing capabilities is reliably creating these unplayable files. We are receiving an increasing number of reports of our app hanging when attempting to play Google Recorder generated M4A files.

How can we gracefully handle these files? Analyze returns an questionable waveform and the player does not return an error. Other players can play these files.

Thank you. Your advice is appreciated.