I am trying to learn to use mini_al to layer looping (streamed) background music with one-shot sound effects (e.g. footsteps), but there don't seem to be examples for layering sounds--only opening a single audio file. Also, it is unclear how one would modify volume. I am sure that all of this is doable, but are there more advanced examples floating around?

This issue is for tracking development and gathering feedback on the new high level API coming to miniaudio. This API sits on top of the existing low level API and will be able to be disabled at compile time for those who don't need or want it thereby not imposing any kind of significant overhead in build size. This is not a replacement for the low level API. It's just an optional high level layer sitting on top of it.

The high level API is for users who don't want or need to do their own mixing and effect processing themselves via the low level API. The problem with the low level API is that as soon as you want to mix multiple sounds you need to do it all manually. The high level API is intended to alleviate this burden from those who don't need or want to do it themselves. This will be useful for game developers in particular.

There's a lot to the high level API, and for practicality I've decided to break it down into parts. This issue relates to the first phase. This phase will be completed before the next begins. The sections below summarise the main features of the high level API. If you have ideas or feedback on features feel free to leave a comment and I'll consider it.

You can use the high level API by doing something like this:

#define MINIAUDIO_IMPLEMENTATION
#include "miniaudio.h"
#include "research/miniaudio_engine.h"

In your header files, just do something like this:

#include "miniaudio.h"
#include "research/miniaudio_engine.h"

Everything is being developed and updated in the dev branch.

Look at miniaudio_engine.h for the code and preliminary documentation. You can probably figure out a lot of features by looking at the header section.

The checklists below are what I'm planning on adding to the high level API. If you have suggestions, leave a comment.

Resource Management

The resource management system is responsible for loading audio data and delivering it to the audio engine.

• [x] Synchronous decoding into in-memory buffers
• [x] Asynchronous decoding into in-memory buffers
• [x] Asynchronous streaming (music, etc.)
• [x] Asynchronous API working with Web/Emscripten (no threading allowed)
• [x] Wide file path support (wchar_t)

The Web/Emscripten backend does not support multithreading. This therefore requires the periodic calling of a function to process the next pending async job, if any, which will need to be done manually by the application.

Engine

The engine is responsible for the management and playback of sounds.

• [x] Sound groups
• [x] Mixing
• [x] Effects
• [x] Volume control
• [x] Panning
• [x] Pitching
• [x] Fading
• [x] Start and stop delays
• [x] Loop points
• [x] Sound cloning for resource managed sounds
• [x] Sound chaining (No gaps allowed. Similar to OpenAL's buffer queue.)

Simple 3D Spatialization

The spatialization model will be simple to begin with. Advanced features such as HRTF will come later once we get an initial implementation done.

• [x] Sound positioning
• [x] Sound orientation / cone attenuation
• [x] Listener positioning
• [x] Listener orientation
• [x] Doppler effect
• [x] Attenuation model (linear and exponential)
• [x] Multiple listeners

Standard Effects Suite

Support for custom effects is implemented, but it would be useful to have a suite of standard effects so applications don't need to implement them themselves.

• [x] Biquad
• [x] LPF
• [x] HPF
• [x] BPF
• [x] Notch Filter
• [x] Peaking Filter
• [x] High / Low Shelf Filters
• [x] Delay / Echo
• [x] Reverb
• [x] Fader
• [x] Stereo Panner

For examples on how to get started, see the _examples folder, and start with engine_hello_world. The general idea is that you have the ma_engine object which you initialize using miniaudio's standard config/init process. You then load sounds which are called ma_sound. The resource manager can be used independently of ma_engine and is called ma_resource_manager. See the resource_manager example for how to use the resource manager manually.

If you're interested in the high level API and it's progress consider subscribing to this issue. I'll be updating this as we go. Feedback is welcome, and I encourage you to play around with it - everything is on the table for review.

Hi @mackron, congrats for such an amazing lib, I've been looking for a library like this for long time now.

I'm thinking about replacing current raylib audio module backend (OpenAL Soft) by mini_al and I would like to know how mini_al compares to OpenAL Soft in features... Actually, I'm mostly just using audio playback for complete loaded sounds and music streaming.

My final goal would be to remove any external library dependency for raylib, I mean, include with raylib basecode all required dependencies.

It appears that on iOS, a pair of Bluetooth headphones will be ignored while the library continues to play audio through the speaker.

This seems like it might be related to the overrideOutputAudioPort call in miniaudio.h:20411. However, it also seems like this might require a categoryOption of AVAudioSessionCategoryOptionAllowBluetoothA2DP.

Do you have any insight into this? In reading through the code it seemed to me like you are generally just dealing with a default audio device and not adjusting routing. The asynchronous nature of much of this framework (AVAudioSession) doesn't seem to match well with the device enumeration in many of the other back ends.

Hi, First off, just wanted to say thanks for all the time and effort you've put into miniaudio. It's a great bit of open source!

I've been running into an odd issue using a duplex stream with the WASAPI backend on Windows 10. After running a duplex stream for a while (~10 minutes) the audio stream will start to stutter. This can on some occasions resolve itself without any intervention (after a couple of minutes), or just keep happening (>10 minutes) till I kill the process.

I managed to record a snippet of what the playback looks like (routed it through some virtual audio cables).

There appear to be short gaps of about ~20ms (most often, but have seen 10ms and 30ms ones) between the audio.

(excuse the poor labelling done in paint job)

I'm using miniaudio through the python bindings of pyminiaudio. I've been recreating the issue on my end, through this python code.

import miniaudio
from time import sleep

if __name__ == "__main__":
    def pass_through():
        data = yield b""
        while True:
            data = yield data

    ....
    duplex = miniaudio.DuplexStream(buffersize_msec=0, sample_rate=48000, playback_device_id=selected_device._id, capture_device_id=c._id)
    generator = pass_through()
    next(generator)
    print("Starting duplex stream. Press Ctrl + C to exit.")
    duplex.start(generator)

    running = True
    while running:
        try:
            sleep(1)
        except KeyboardInterrupt:
            running = False
    duplex.stop()

From my debugging so far, I'm fairly sure that issue isn't being caused by Python. I've profiled how long the various callbacks are to see if a slowdown in Python was causing the stuttering, but haven't discovered any. Hence, I believe the issue is happening at the C level in miniaudio.

For the example above, I believe the C equivalent duplex streams setting, would be this:

ma_device_config config = ma_device_config_init(ma_device_type_duplex);   
config.playback.pDeviceID = &myPlaybackDeviceID; 
config.playback.format    = ma_format_s16;
config.playback.channels  = 2;
config.capture.pDeviceID  = &myCaptureDeviceID; 
config.capture.format     = ma_format_s16;
config.capture.channels   = 2;
config.sampleRate         = 48000;
config.dataCallback       = data_callback;
config.bufferSizeInMilliseconds = 0;

Other observations I've made:

• I don't think bufferSizeInMilliseconds is triggering this issue? It has happened when set to 0 and 100.
• No resampling should be occurring. The capture and playback devices both natively support 16bit 48kHz and should be running in shared mode (if that is the default)

Any ideas on what could be happening? I'm happy to provide any more information, just let me know what would be helpful.

mini_al - v0.8.10 - 2018-10-21

line 13632 : #include <AVFoundation/AVFoundation.h>

build error : Could not build module 'AVFoundation' i have already add the AVFoundation.framework

i test it and success on macOS, but ios cant compile

my work that export minial to java throuth jni.

Hi. Congratulations for the work done for the past months since the last time we interacted!

Context

I'm writing a program that so far opens a device full-duplex to record sound and play the same. It will do something else later.

By default miniaudio tried to reach pulseaudio, which is fine until something wrong happens.

Observed

The program starts (and chooses a correct full-duplex device), but receives no audio (the callback is not called regulary, only a few times in the first seconds). But if I run pavucontrol, then the program receives audio normally and produces a correct record file. And when pavucontrol stops, the program no longer receives audio regularly. I can start and stop pavucontrol as many times as I want, the effect happens.

In #57 you offered me to try to compile with MA_NO_PULSEAUDIO defined. I tried that.

With that option, the problem no longer happens. We have the expected behavior.

Expected

Program captures audio (and plays it simultaneously), whether pavucontrol is opened or not.

Additional information

• simple_playback has no such issue.
• (More could be discussed, but let's stay simple for one issue report) I had to make sure that the wished devices are the default devices in pulseaudio. This can be discussed separately.
• Fun fact: the default ALSA device is the one that routes through pulseaudio, so technically miniaudio still uses pulse but does not know it.

But why mentioning simple_capture in title then?

Because I though maybe I use the miniaudio API wrong, or maybe this is specific to full-duplex. So, to simplify the issue I checked behavior of simple_capture. And I confirm that the issue also happens. Exactly the same. And the same workaround. So, the problem is unrelated to fullduplex.

Software environment

Xubuntu 18.04. miniaudio current git master:

commit 1ca6f80698acbdbf9ae4a9f4200975d919de31f8
Author: David Reid <[email protected]>
Date:   2019-10-19 07:46:44 +1000

    Fix some tests.

    These compilation errors are a result of the recent change to dr_wav to
    add support for allocation callbacks.

What now?

I can do more tests if you wish, like last time, with specific build options, bring logs, share my complete programs if needed. So far, been using this:

gcc ../simple_capture.c -DMA_DEBUG_OUTPUT=true -o ../bin/simple_capture -Wall -Wpedantic -pedantic -lpthread -ldl -lm

For those who are interested, I'm preparing the next version of miniaudio which has now reached the testing phase. This is version 0.10 and includes some breaking changes and some significant refactoring to some internals. As a result of this refactoring there's a good chance I've introduced some bugs, and although all of my own tests are passing, it'd be nice to get a bit more testing coverage before pushing out the new version. If anyone's willing to give it a try I'd be grateful! You can find it in the dev branch.

The main thing that has changed is the data conversion pipeline. This is the part of the code that converts between the format you request when initializing the ma_device object and the format of the backend's internal device. The tricky part is that there's so many different permutations it's quite hard to hit every case on every platform, so it'd be nice to get some extra coverage from the community. What you're listening for is any kinds of clicks or general glitching. The ma_decoder APIs also use the data conversion pipeline so that is something else to take a look at if you're using that.

If you're using the old data conversion pipeline you may want to hold off updating until you can find the time to refactor for the new API as it won't be a trivial update. Gone are the old ma_format_converter, ma_channel_router, ma_src and ma_pcm_converter. These have been replaced with ma_channel_converter, ma_resampler and ma_data_converter. The old callback based system has been removed completely and replaced with a more iterative solution - you call ma_data_converter_process_pcm_frames() and pass in a buffer to the input and output buffers. Upon returning it will return the number of input and output frames that were actually processed. You can then use this information to implement an iterative data conversion solution.

There's a few other changes, but it's doubtful these will cause any major issues. I will be preparing release notes soon.

@raysan5 raylib is using the old ma_pcm_converter so you may want to hold off updating for the time being. I can prepare a pull request for you in the coming days, if you like?

So this is the callstack which occasionally appears at the start of playback of my ffmpeg-based video player stream:

...not much to go on. I did a little research and found only this relating to VLC from some time ago:

https://trac.videolan.org/vlc/ticket/10775

The fix the VLC team applied implies that this particular callstack appears if the OnPropertyChanged function does not exist.

Well, it exists in miniaudio, so if miniaudio is at fault it's not as simple as the issue VLC had.

Here is the debug output when the crash does not occur:

[miniaudio] Endian: LE [miniaudio] SSE2: YES [miniaudio] AVX2: YES [miniaudio] AVX512F: NO [miniaudio] NEON: NO [WASAPI] Trying IAudioClient3_InitializeSharedAudioStream(actualPeriodInFrames=480) defaultPeriodInFrames=480 fundamentalPeriodInFrames=480 minPeriodInFrames=480 maxPeriodInFrames=480 [WASAPI] Using IAudioClient3 periodSizeInFramesOut=480 bufferSizeInFramesOut=1440 [WASAPI] Realtek Digital Output (Realtek(R) Audio) (Playback) Format: 32-bit IEEE Floating Point -> 32-bit IEEE Floating Point Channels: 2 -> 2 Sample Rate: 48000 -> 48000 Buffer Size: 1440/3 (480) Conversion: Pre Format Conversion: NO Post Format Conversion: NO Channel Routing: NO SRC: NO Channel Routing at Start: NO Passthrough: YES IMMNotificationClient_OnPropertyValueChanged(pDeviceID={0.0.0.00000000}.{deca6857-4151-4f80-bda5-d5a85e606755})

As can be seen, the OnPropertyValueChanged function is called successfully.

Here is the trace when it crashes.

[WASAPI] Trying IAudioClient3_InitializeSharedAudioStream(actualPeriodInFrames=480) defaultPeriodInFrames=480 fundamentalPeriodInFrames=480 minPeriodInFrames=480 maxPeriodInFrames=480 [WASAPI] Using IAudioClient3 periodSizeInFramesOut=480 bufferSizeInFramesOut=1440 [WASAPI] Realtek Digital Output (Realtek(R) Audio) (Playback) Format: 32-bit IEEE Floating Point -> 32-bit IEEE Floating Point Channels: 2 -> 8 Sample Rate: 48000 -> 48000 Buffer Size: 1440/3 (480) Conversion: Pre Format Conversion: YES Post Format Conversion: YES Channel Routing: YES SRC: NO Channel Routing at Start: NO Passthrough: NO

So pretty much the same, but it never reaches the OnPropertyValueChanged function so the debug for that is missing. (Probably a side issue, or non-issue, but Passthrough sometimes shows YES and sometimes shows NO for the same source type, but this does not correspond with whether it does or does not crash).

So I am wondering if there is some kind of timing/race condition that means that the MMDevAPI tries to call the OnPropertyValueChanged function before it has been registered, or something? Certainly, it always seems to want to call it at the beginning of the stream, shortly after starting the audio device.

Finally, the crash occurs regardless of whether I actually pass miniaudio any data via the callback; I disabled writing audio data to my buffer, and it still can crash while sitting waiting in the audio callback for the first samples (i.e. I have it waiting on a condition variable). Or is *that approach itself the wrong one?

EDIT: *just to clarify what I am doing. Once my audio decoder has started receiving data, I call ma_device_init() then ma_device_start(). I assume then it goes and calls my callback pretty soon afterwards, which sits waiting on a condition variable until I write data into a buffer and notify the CV. In the case of my player, this may not be the initial audio data in the stream, as the AV sync mechanism my ditch some of the first audio packets. Once the callback has the amount of data requested, it reads it from the buffer into the buffer supplied to the callback and returns. So I am speculating that maybe if I am calling ma_device_start() without immediately providing some data for the callback that this could lead to this situation happening.

Hi, I'm having a incredibly bad cracking with anything played trough mini_al.

The code adapted from the sample with a few tweaks to chose the backend (copied from another issue here): https://gist.github.com/fungos/7fa6fb159f8fd260ed5aca17b1c0bc5c In this gist there is the link for the input mp3 sample and the output recorded from another device, as if I try to record directly from the pulseaudio sink, the sound is perfect.

I've tried with SDL, OpenAL, PluseAudio, ALSA and OSS backends, all these have the same issue. I don't have any issue at all playing any audio in this desktop with any other software, so I imagine it must be related to some mis-configuration initializing mini_al or some initialization internally.

I want to replace BASS audio in a game port I'm doing, and mini_al sounded ideal for the job, I hope to be able to figure this problem :)

Thanks

Hello, first off great work on this library!

We're using your library in our project (https://github.com/Soundux/Soundux) and we have a few users that report problems related to crashing.

This snippet crashes for some people:

  std::string defaultName;
  {
    ma_device device;
    ma_device_config deviceConfig =
        ma_device_config_init(ma_device_type_playback);
    ma_device_init(nullptr, &deviceConfig, &device);

    defaultName = device.playback.name;

    ma_device_uninit(&device);
  }
  std::cout << "Default device is: " << defaultName << std::endl;

With MA_DEBUG_OUTPUT defined this is printed:

[miniaudio] Endian:  LE
[miniaudio] SSE2:    YES
[miniaudio] AVX2:    NO
[miniaudio] AVX512F: NO
[miniaudio] NEON:    NO
[PulseAudio] Playback attr: maxlength=0, tlength=0, prebuf=-1, minreq=-1, fragsize=0; periodSizeInFrames=480
[1]    6815 floating point exception (core dumped)  ./miniaudio-SIGFPE

This is a reproduction example:

#define MINIAUDIO_IMPLEMENTATION
#define MA_DEBUG_OUTPUT
#include "miniaudio.h"
#include <iostream>
#include <string>

int main() {
  std::string defaultName;
  {
    ma_device device;
    ma_device_config deviceConfig =
        ma_device_config_init(ma_device_type_playback);
    ma_device_init(nullptr, &deviceConfig, &device);

    defaultName = device.playback.name;

    ma_device_uninit(&device);
  }
  std::cout << "Default device is: " << defaultName << std::endl;

  ma_context context;

  if (ma_context_init(nullptr, 0, nullptr, &context) != MA_SUCCESS) {
    std::cerr << "Failed to initialize context" << std::endl;
    return {};
  }

  ma_device_info *pPlayBackDeviceInfos{};
  ma_uint32 deviceCount{};

  ma_result result = ma_context_get_devices(&context, &pPlayBackDeviceInfos,
                                            &deviceCount, nullptr, nullptr);
  if (result != MA_SUCCESS) {
    std::cerr << "Failed to get playback devices!" << std::endl;
    return {};
  }

  for (unsigned int i = 0; deviceCount > i; i++) {
    auto &rawDevice = pPlayBackDeviceInfos[i];
    std::cout << "Got device: " << rawDevice.name << std::endl;
  }

  ma_context_uninit(&context);
  return 0;
}

However I was not able to reproduce this on any of my (virtual-)machines.

Our related issue is here: https://github.com/Soundux/Soundux/issues/253

The person that has experienced this issue is @PatrickJosh We had this problem before but the person that reported it a while back could fix the issue by deleting their pulseaudio config

Documentation states that it should be possible to change the type of the noise dynamically:

The amplitude, seed, and type can be changed dynamically with `ma_noise_set_amplitude()`,
`ma_noise_set_seed()`, and `ma_noise_set_type()` respectively.

I get a crash when trying to change the noise type after calling ma_noise_init(). Looking at the ma_noise_init() code I can see:

    /* Pink. */
    if (pConfig->type == ma_noise_type_pink) {
        // ...
    }

    /* Brownian. */
    if (pConfig->type == ma_noise_type_brownian) {
       // ...
    }

So, there is a dedicated init code for different noise types and this code is not executed when the noise type is changed dynamically with ma_noise_set_type().

Hello mackron,

I have encountered a crash with Miniaudio (c153a94) on Windows that happens when the user unplugs/plugs a USB audio device during an ongoing execution of ma_engine_init().

I have created a simple test program for VisualStudio that can be used to reproduce the issue with close to 100% probability, the code can be found here:

MiniAudioTest

Just run the test program, which will basically call ma_engine_init() / ma_engine_uninit() in an infinite loop, and then plug/unplug a USB audio device until the crash happens (usually happens after 1-3 plugs)

The crash seems to happen due to a null pointer exception in ma_IAudioClient_Start() where pThis appears to be NULL:

My best guess is this happens due to lack of thread safety between the ma_worker_thread() (triggered by ma_engine_init()), where the crash happens, and the thread kicked off by ma_IMMNotificationClient_OnDefaultDeviceChanged(). Here's a parallel stack taken at the time the issue happened:

Note:

I was only able to test this on a Windows machine. My guess is however, if there are equivalents to ma_IMMNotificationClient_OnDefaultDeviceChanged() et. al on other platforms, the issue will happen there as well.

Please find attached the log taken with the MA_DEBUG_OUTPUT flag.

log.txt

I would kindly appreciate it if you could take a look

Best regards, Marcus

Discussed in https://github.com/mackron/miniaudio/discussions/547

I created this issue to follow up it from this disussion.

I tested the dev branch: The issue is solved with the new code implementation, but thanks to that I found another issue. It is difficult to explain, so I'll make a table to organize the issue.

| | Falloff > 0 | Falloff == 0 | |----------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------:| | Delay dry==0 | Dry signal still sounds (issue). I think the problem is that "wet" signal has the initial "sound". In a wet signal, you only have the delayed sound, not the first one. | Works perfectly, this is what your new code implementation solved | | Delay dry > 0 | The dry signal sounds but not in the ratio inputted in "ma_delay_node_set_dry"(issue). It sounds full volume, as if dry would be 1.0f | The dry signal does not sound anymore (issue). The inicial sound should be listened at the ratio inputed with the function "ma_delay_node_set_dry" |

Cosmopolitan is a C standard library that allows building statically linked binaries that run under Windows, Mac, Linux and a few other platforms all at the same time. Since it does not have an easy / good way to play audio (AKA Miniaudio) and Miniaudio is already cross-platform, it seems like it'd be a pretty good fit, however it might be a good bit of work. Since these binaries could run anywhere, it'd have to contain code for all supported backends, then at runtime we detect the platform and enable the right ones. I believe Cosmopolitan wraps a lot of the Windows API and allows calling into it pretty easily but you'll get an error code at runtime if not on Windows. Don't know about anything else, but we link to those at runtime which might make things easier. Hopefully these links help: Building actually portable executables on Windows Cosmopolitan home page Cosmopolitan on Github

Windows supports capturing/excluding the audio of a specific process/process tree. I would like to set the ProcessLoopbackParams that is passed to the windows api. Related: https://docs.microsoft.com/en-us/samples/microsoft/windows-classic-samples/applicationloopbackaudio-sample/ https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/ApplicationLoopback

I've caught a crash while was testing my application with google test framework. The same happened when I just substituted my code with the Simple Playback sample. The resulted code consists of 2 tests each of which contains the duplicate of the Simple Playback sample code. As soon as the first test passed, the crash occurs as a result of running the second one after calling ma_device_start function. The callback works for awhile and then crashes.

As an attempt to find out what happened I tried to remove ma_device_uninit function from the first test and the second test with the application code didn't crash again. However the same doesn't work with samples. It looks like there is a problem with ma_device_uninit function which doesn't perform full cleanup.

It's not an issue with AAudio itself because I use Oboe Library with the same application and it works well.

Steps to reproduce: Precondition: not empty WAV file.

1. Launch 2 samples of the Simple Playback one after another in a single instance of application.
2. Observe the crash.

OS: Android 11 (AAudio) HW: both Emulator (x86_64) and Device (aarmv8) Occurence: 100%

Full log:

05-10 15:43:13.933 8454 8478 D com.garmony_o.tests.unittestrunner.MainActivity: [ RUN ] AudioOutTest.MA_SAMPLE_1 05-10 15:43:13.941 8482 8482 I AAudio : AAudioStreamBuilder_openStream() called ---------------------------------------- 05-10 15:43:13.942 8482 8482 I AudioStreamBuilder: rate = 22050, channels = 1, format = 1, sharing = SH, dir = OUTPUT 05-10 15:43:13.942 8482 8482 I AudioStreamBuilder: device = 0, sessionId = -1, perfMode = 12, callback: ON with frames = 220 05-10 15:43:13.942 8482 8482 I AudioStreamBuilder: usage = 0, contentType = 0, inputPreset = 0, allowedCapturePolicy = 0 05-10 15:43:13.942 8482 8482 I AudioStreamBuilder: privacy sensitive = false 05-10 15:43:13.942 8482 8482 D testGarmony_o: PlayerBase::PlayerBase() 05-10 15:43:13.922 8482 8482 W Thread-2: type=1400 audit(0.0:188): avc: granted { execute } for name="testGarmony_o" dev="dm-5" ino=131088 scontext=u:r:untrusted_app_27:s0:c131,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c131,c256,c512,c768 tclass=file app=com.garmony_o.tests.unittestrunner 05-10 15:43:13.944 8482 8482 D AudioStreamTrack: open(), request notificationFrames = 220, frameCount = 660 05-10 15:43:13.952 507 2368 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:13.952 507 2368 I chatty : uid=1000(system) Binder:507_13 identical 2 lines 05-10 15:43:13.952 507 2368 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:13.926 8482 8482 W Thread-2: type=1400 audit(0.0:189): avc: granted { execute_no_trans } for path="/data/user/0/com.garmony_o.tests.unittestrunner/files/testGarmony_o" dev="dm-5" ino=131088 scontext=u:r:untrusted_app_27:s0:c131,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c131,c256,c512,c768 tclass=file app=com.garmony_o.tests.unittestrunner 05-10 15:43:13.957 370 455 W AudioFlinger: createTrack_l(): mismatch between requested flags (00000104) and output flags (00000002) 05-10 15:43:13.926 8482 8482 W testGarmony_o: type=1400 audit(0.0:190): avc: granted { execute } for path="/data/user/0/com.garmony_o.tests.unittestrunner/files/testGarmony_o" dev="dm-5" ino=131088 scontext=u:r:untrusted_app_27:s0:c131,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c131,c256,c512,c768 tclass=file app=com.garmony_o.tests.unittestrunner 05-10 15:43:13.969 370 455 D AF::TrackHandle: OpPlayAudio: track:181 usage:1 not muted 05-10 15:43:13.972 8482 8482 D AudioTrack: createTrack_l(0): AUDIO_OUTPUT_FLAG_FAST denied by server; frameCount 660 -> 984 05-10 15:43:13.975 8482 8482 D AAudioStream: setState(s#1) from 0 to 2 05-10 15:43:13.976 8482 8482 W AudioStreamTrack: open() flags changed from 0x00000104 to 0x00000000 05-10 15:43:13.976 8482 8482 W AudioStreamTrack: open() perfMode changed from 12 to 10 05-10 15:43:13.977 8482 8482 I AAudio : AAudioStreamBuilder_openStream() returns 0 = AAUDIO_OK for s#1 ---------------- 05-10 15:43:13.977 8482 8482 D AAudio : AAudioStream_requestStart(s#1) called -------------- 05-10 15:43:13.977 8482 8482 D AAudioStream: setState(s#1) from 2 to 3 05-10 15:43:13.978 370 455 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:13.978 370 455 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:13.979 8482 8482 D testGarmony_o: PlayerBase::start() from IPlayer 05-10 15:43:13.979 8482 8482 D AAudio : AAudioStream_requestStart(s#1) returned 0 --------- 05-10 15:43:13.980 507 2943 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:13.980 8482 8488 D AudioStreamLegacy: onAudioDeviceUpdate() devId 2 => 2 05-10 15:43:13.987 8482 8485 D AAudioStream: setState(s#1) from 3 to 4 05-10 15:43:14.039 370 457 D AudioFlinger: mixer(0x75dfdd75a040) throttle end: throttle time(9) 05-10 15:43:14.914 507 1285 E TaskPersister: File error accessing recents directory (directory doesn't exist?). 05-10 15:43:16.937 2551 2551 I perfetto: probes_producer.cc:329 Producer stop (id=62) 05-10 15:43:16.941 2551 2551 I perfetto: ftrace_procfs.cc:183 disabled ftrace 05-10 15:43:16.942 412 412 I perfetto: ng_service_impl.cc:1948 Tracing session 62 ended, total sessions:0 05-10 15:43:16.929 0 0 W perfetto: disabled ftrace 05-10 15:43:16.955 507 2680 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.003 8482 8482 D AAudio : AAudioStream_requestStop(s#1) called 05-10 15:43:19.003 8482 8482 D AAudioStream: setState(s#1) from 4 to 9 05-10 15:43:19.003 8482 8482 D AudioTrack: stop(176): called with 112200 frames delivered 05-10 15:43:19.004 8482 8482 D testGarmony_o: PlayerBase::stop() from IPlayer 05-10 15:43:19.004 8482 8482 D AAudioStream: setState(s#1) from 9 to 10 05-10 15:43:19.004 8482 8482 D AAudio : AAudioStream_close(s#1) called --------------- 05-10 15:43:19.004 8482 8482 D AAudioStream: setState(s#1) from 10 to 11 05-10 15:43:19.004 8482 8482 D AAudioStream: setState(s#1) from 11 to 12 05-10 15:43:19.010 8482 8482 D AAudio : AAudioStream_close(s#1) returned 0 --------- 05-10 15:43:19.012 8482 8482 I BpBinder: onLastStrongRef automatically unlinking death recipients: 05-10 15:43:19.012 8482 8482 I chatty : uid=10131(com.garmony_o.tests.unittestrunner) /data/user/0/com.garmony_o.tests.unittestrunner/files/testGarmony_o identical 1 line 05-10 15:43:19.012 8482 8482 I BpBinder: onLastStrongRef automatically unlinking death recipients: 05-10 15:43:19.014 8454 8478 D com.garmony_o.tests.unittestrunner.MainActivity: [ OK ] AudioOutTest.MA_SAMPLE_1 (5081 ms) 05-10 15:43:19.014 8454 8478 D com.garmony_o.tests.unittestrunner.MainActivity: [ RUN ] AudioOutTest.MA_SAMPLE_2 05-10 15:43:19.022 8482 8482 I AAudio : AAudioStreamBuilder_openStream() called ---------------------------------------- 05-10 15:43:19.022 8482 8482 I AudioStreamBuilder: rate = 22050, channels = 1, format = 1, sharing = SH, dir = OUTPUT 05-10 15:43:19.022 8482 8482 I AudioStreamBuilder: device = 0, sessionId = -1, perfMode = 12, callback: ON with frames = 220 05-10 15:43:19.022 8482 8482 I AudioStreamBuilder: usage = 0, contentType = 0, inputPreset = 0, allowedCapturePolicy = 0 05-10 15:43:19.022 8482 8482 I AudioStreamBuilder: privacy sensitive = false 05-10 15:43:19.022 8482 8482 D testGarmony_o: PlayerBase::PlayerBase() 05-10 15:43:19.023 8482 8482 D AudioStreamTrack: open(), request notificationFrames = 220, frameCount = 660 --------- beginning of crash 05-10 15:43:19.026 8482 8488 F libc : Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x76b698399e10 in tid 8488 (Binder:8482_2), pid 8482 (testGarmony_o) 05-10 15:43:19.027 507 2943 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.027 507 2943 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.029 370 828 W AudioFlinger: createTrack_l(): mismatch between requested flags (00000104) and output flags (00000002) 05-10 15:43:19.034 370 828 D AF::TrackHandle: OpPlayAudio: track:182 usage:1 not muted 05-10 15:43:19.036 8482 8482 D AudioTrack: createTrack_l(176): AUDIO_OUTPUT_FLAG_FAST denied by server; frameCount 660 -> 984 05-10 15:43:19.038 8482 8482 D AAudioStream: setState(s#1) from 0 to 2 05-10 15:43:19.039 370 445 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:19.039 370 445 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:19.041 507 2943 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.045 8482 8482 W AudioStreamTrack: open() flags changed from 0x00000104 to 0x00000000 05-10 15:43:19.045 8482 8482 W AudioStreamTrack: open() perfMode changed from 12 to 10 05-10 15:43:19.049 8482 8482 I AAudio : AAudioStreamBuilder_openStream() returns 0 = AAUDIO_OK for s#1 ---------------- 05-10 15:43:19.050 8482 8482 D AAudio : AAudioStream_requestStart(s#1) called -------------- 05-10 15:43:19.050 8482 8482 D AAudioStream: setState(s#1) from 2 to 3 05-10 15:43:19.051 370 828 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:19.051 370 828 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:19.051 8482 8482 D testGarmony_o: PlayerBase::start() from IPlayer 05-10 15:43:19.052 8482 8482 D AAudio : AAudioStream_requestStart(s#1) returned 0 --------- 05-10 15:43:19.061 8482 8490 D AAudioStream: setState(s#1) from 3 to 4 05-10 15:43:19.061 507 2680 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.075 8495 8495 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 05-10 15:43:19.077 264 264 I tombstoned: received crash request for pid 8488 05-10 15:43:19.079 8495 8495 I crash_dump64: performing dump of process 8482 (target tid = 8488) 05-10 15:43:19.085 8495 8495 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 05-10 15:43:19.085 8495 8495 F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:11/RSR1.210722.012/7758210:userdebug/test-keys' 05-10 15:43:19.085 8495 8495 F DEBUG : Revision: '0' 05-10 15:43:19.085 8495 8495 F DEBUG : ABI: 'x86_64' 05-10 15:43:19.087 8495 8495 F DEBUG : Timestamp: 2022-05-10 15:43:19+0700 05-10 15:43:19.088 8495 8495 F DEBUG : pid: 8482, tid: 8488, name: Binder:8482_2 >>> /data/user/0/com.garmony_o.tests.unittestrunner/files/testGarmony_o <<< 05-10 15:43:19.088 8495 8495 F DEBUG : uid: 10131 05-10 15:43:19.088 8495 8495 F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x76b698399e10 05-10 15:43:19.088 8495 8495 F DEBUG : rax 0000000000000000 rbx 0000000000000100 rcx 6f1ff8da08198821 rdx 000076b697f43b30 05-10 15:43:19.088 8495 8495 F DEBUG : r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000206 05-10 15:43:19.088 8495 8495 F DEBUG : r12 000076b7f8de7130 r13 000076b697f43b30 r14 000076b7f8de71d8 r15 000076b7f8de7250 05-10 15:43:19.088 8495 8495 F DEBUG : rdi 0000000000000005 rsi 00000000c0306201 05-10 15:43:19.089 8495 8495 F DEBUG : rbp 00000000fffffff7 rsp 000076b697f43b10 rip 000076b698399e10 05-10 15:43:19.089 8495 8495 F DEBUG : backtrace: 05-10 15:43:19.089 8495 8495 F DEBUG : #00 pc 000000000000ee10 /system/lib64/libaudioutils.so (BuildId: dc8b91cfb333c513abb18860cb60f824) 05-10 15:43:19.107 0 0 D logd : logdr: UID=10131 GID=10131 PID=8495 n tail=50 logMask=8 pid=8482 start=0ns timeout=0ns 05-10 15:43:19.111 0 0 D logd : logdr: UID=10131 GID=10131 PID=8495 n tail=50 logMask=1 pid=8482 start=0ns timeout=0ns 05-10 15:43:19.149 0 0 D logd : logdr: UID=10131 GID=10131 PID=8495 n tail=0 logMask=8 pid=8482 start=0ns timeout=0ns 05-10 15:43:19.151 0 0 D logd : logdr: UID=10131 GID=10131 PID=8495 n tail=0 logMask=1 pid=8482 start=0ns timeout=0ns 05-10 15:43:19.166 507 695 W NativeCrashListener: Couldn't find ProcessRecord for pid 8482 05-10 15:43:19.166 264 264 E tombstoned: Tombstone written to: /data/tombstones/tombstone_04 05-10 15:43:19.170 507 545 I BootReceiver: Copying /data/tombstones/tombstone_04 to DropBox (SYSTEM_TOMBSTONE) 05-10 15:43:19.171 507 545 I DropBoxManagerService: add tag=SYSTEM_TOMBSTONE isTagEnabled=true flags=0x2 05-10 15:43:19.194 8454 8478 D com.garmony_o.tests.unittestrunner.MainActivity: Finished executing binary 05-10 15:43:19.180 0 0 I init : Untracked pid 8495 exited with status 0 05-10 15:43:19.185 0 0 I binder : undelivered transaction 997114, process died. 05-10 15:43:19.186 0 0 I binder : undelivered transaction 997174, process died. 05-10 15:43:19.190 0 0 I binder : undelivered transaction 997182, process died. 05-10 15:43:19.195 0 0 I init : Untracked pid 8497 exited with status 0 05-10 15:43:19.199 0 0 I binder : undelivered transaction 997193, process died. 05-10 15:43:19.241 507 2680 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4 05-10 15:43:19.241 370 445 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:19.241 370 445 W APM::AudioPolicyEngine: getDevicesForStrategy() unknown strategy: -1 05-10 15:43:22.040 507 2943 I system_server: oneway function results will be dropped but finished with status OK and parcel size 4