Comments (9)
@JP-Lisn - thanks for the info.
I'm glad the shared_ptr worked.
A warning log when deprecated (not depreciated) methods are called would be wonderful!
We would welcome a PR.
from oboe.
I was incorrect, the issue still persists...
from oboe.
Please refer to our minimaloboe sample for how to fill the buffer in onAudioReady().
Here is an example where memset is called from a callback.
from oboe.
(Sorry for assigning back to you without an explanation. I had written some questions but forgot to post them.)
segmentation fault when trying to initialize the passed void *audioData pointer to 0.
What does that code look like? Are you using memset()?
How are you calculating the number of bytes for memset()?
Are you using the numFrames passed into the callback? It can vary!
Is a headset being unplugged or plugged in? There are often bugs related to that event.
from oboe.
Thanks for these resources, my code does follow the example although through a slightly different route to calculate the buffer size.
oboe::DataCallbackResult onAudioReady(oboe::AudioStream *outputStream, void *audioData, int32_t numFrames) override {
...
int32_t expectedSizeBytes = numFrames * outputStream->getBytesPerFrame();
std::memset(audioData, 0, expectedSizeBytes);
...
During debugging of this issue today it appears this code is working at least one another device, our [gts8wifi, SM-X700, samsung, 33] but not on the pixel 6 pro [raven, Pixel 6 Pro, Google, 33]. We took a look at the diff our our logcat output between devices the only difference I can see is further down the pipe.
We don't currently have headphones connected when we have been debugging this issue.
from oboe.
I notice your INPUT has a SesionID
15139-15139 AudioStreamBuilder com.lisn.framework_testapp I device = 0, sessionId = 18705, perfMode = 12, callback: OFF with frames = 0
What effects are you using on INPUT?
If you don't use effects does it sill crash?
If you don't pass a Session ID does it still crash?
Maybe outputStream->getBytesPerFrame() is returning a bad value?
For stereo float it should be 2*4 = 8.
768/8 is 96, which is a common burst size. So it is probably right.
Is it possible the stream is getting closed from another thread?
Does the crash happen on the first callback or later?
from oboe.
I notice your INPUT has a SesionID
Correct, I am attaching to an audio session in this case. The audio session is obtained from an exoplayer instance and passed to our library upon initialization. One of our objectives is to evaluate attaching to a session, we have read and realized that this is not the recommended route for low latency reasons but wanted to see what we could achieve before tackling media decoding.
What effects are you using on INPUT?
If you don't use effects does it sill crash?
If you don't pass a Session ID does it still crash?
Our library will provide effects to process the audio, in this situation we only have one effect node in play, a simple linear gain. However, the effect rendering does not occur as our failure point is during the initialization of *audiodata
to 0, before our effect rendering procedure occurs within the onDataReady
callback.
The same error occurs when I omit the SessionID and the input stream binds to the microphone. It does not seem to be associated with the input source.
Maybe outputStream->getBytesPerFrame() is returning a bad value?
For stereo float it should be 2*4 = 8.
768/8 is 96, which is a common burst size. So it is probably right.
I did validate that the different route I took in the calculation resulted in the same value as other methods. Along the same thought processes I also tried to determine if the audioData
buffer pointer was failing "at some point" so I temporarily replaced the memset call with a for loop which incremented the pointer, but the failure always occurred on the first value.
Is it possible the stream is getting closed from another thread?
Everything in regard to stream operations occurs on the main thread.
Does the crash happen on the first callback or later?
The crash occurs on the first run of the callback.
When comparing the run on a the working samsung tab, we did notice some slight differences in the logcat output:
Crashing pixel:
StreamDataCallback com.lisn.framework_testapp I StreamDataCallback initialized
OboeAudio com.lisn.framework_testapp I openStream() OUTPUT -------- OboeVersion1.7.5 --------
AAudio com.lisn.framework_testapp I AAudioStreamBuilder_openStream() called ----------------------------------------
AudioStreamBuilder com.lisn.framework_testapp I rate = 48000, channels = 2, channelMask = 0x80000003, format = 5, sharing = EX, dir = OUTPUT
AudioStreamBuilder com.lisn.framework_testapp I device = 0, sessionId = -1, perfMode = 12, callback: ON with frames = 0
AudioStreamBuilder com.lisn.framework_testapp I usage = 1, contentType = 2, inputPreset = 6, allowedCapturePolicy = 0
AudioStreamBuilder com.lisn.framework_testapp I privacy sensitive = false, opPackageName = (null), attributionTag = (null)
amework_testapp com.lisn.framework_testapp D PlayerBase::PlayerBase()
AudioStr..._Client com.lisn.framework_testapp D configureDataInformation() original HW burst = 48, minMicros = 2000 => SW burst = 96
AAudioStream com.lisn.framework_testapp D setState(s#2) from 0 to 2
AAudioFlowGraph com.lisn.framework_testapp I configure() source format = 0x00000005, channels = 2, sink format = 0x00000005, channels = 2, useMonoBlend = 0, audioBalance = 0.000000, isExclusive 1
AAudio com.lisn.framework_testapp I AAudioStreamBuilder_openStream() returns 0 = AAUDIO_OK for s#2 ----------------
OboeAudio com.lisn.framework_testapp D AudioStreamAAudio.open() format=2, sampleRate=48000, capacity = 1920
OboeAudio com.lisn.framework_testapp D calculateDefaultDelayBeforeCloseMillis() default = 10
OboeAudio com.lisn.framework_testapp D AudioStreamAAudio.open: AAudioStream_Open() returned AAUDIO_OK = 0
Vs non-chashing samsung:
StreamDataCallback com.lisn.framework_testapp I StreamDataCallback initialized
OboeAudio com.lisn.framework_testapp I openStream() OUTPUT -------- OboeVersion1.7.5 --------
AAudio com.lisn.framework_testapp I AAudioStreamBuilder_openStream() called ----------------------------------------
AudioStreamBuilder com.lisn.framework_testapp I rate = 48000, channels = 2, channelMask = 0x80000003, format = 5, sharing = EX, dir = OUTPUT
AudioStreamBuilder com.lisn.framework_testapp I device = 0, sessionId = -1, perfMode = 12, callback: ON with frames = 0
AudioStreamBuilder com.lisn.framework_testapp I usage = 1, contentType = 2, inputPreset = 6, allowedCapturePolicy = 0
AudioStreamBuilder com.lisn.framework_testapp I privacy sensitive = false, opPackageName = (null), attributionTag = (null)
amework_testapp com.lisn.framework_testapp D PlayerBase::PlayerBase()
DMCodecA...Factory com.lisn.framework_testapp I Creating an asynchronous MediaCodec adapter for track type audio
CCodec com.lisn.framework_testapp I state->set(ALLOCATING)
CCodec com.lisn.framework_testapp I allocate(c2.sec.flac.decoder)
Codec2Client com.lisn.framework_testapp I Available Codec2 services: "default" "default0" "software"
CCodec com.lisn.framework_testapp I setting up 'default' as default (vendor) store
amework_testapp com.lisn.framework_testapp D PlayerBase::PlayerBase()
AudioStr..._Client com.lisn.framework_testapp D ~AudioStreamInternal() 0xb400006ffef9cfd0 called
AAudioStream com.lisn.framework_testapp D ~AudioStream(s#2) mPlayerBase strongCount = 1
amework_testapp com.lisn.framework_testapp D PlayerBase::~PlayerBase()
AudioStreamTrack com.lisn.framework_testapp D open(), request notificationFrames = -8, frameCount = 0
AudioTrack com.lisn.framework_testapp I createTrack_l(0): AUDIO_OUTPUT_FLAG_FAST successful; frameCount 0 -> 1536
CCodec com.lisn.framework_testapp I Created component [c2.sec.flac.decoder]
CCodec com.lisn.framework_testapp I [c2.sec.flac.decoder] state->set(ALLOCATED)
CCodecConfig com.lisn.framework_testapp D read media type: audio/flac
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: algo.buffers.max-count.values
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: output.subscribed-indices.values
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: input.buffers.allocator-ids.values
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: output.buffers.allocator-ids.values
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: algo.buffers.allocator-ids.values
AudioTrack com.lisn.framework_testapp D setVolume(1.000000, 1.000000) pid : 4043
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: output.buffers.pool-ids.values
Reflecte...Updater com.lisn.framework_testapp D extent() != 1 for single value type: algo.buffers.pool-ids.values
AAudioStream com.lisn.framework_testapp D setState(s#3) from 0 to 2
AAudio com.lisn.framework_testapp I AAudioStreamBuilder_openStream() returns 0 = AAUDIO_OK for s#3 ----------------
OboeAudio com.lisn.framework_testapp D AudioStreamAAudio.open() format=2, sampleRate=48000, capacity = 1536
OboeAudio com.lisn.framework_testapp D calculateDefaultDelayBeforeCloseMillis() default = 10
OboeAudio com.lisn.framework_testapp D AudioStreamAAudio.open: AAudioStream_Open() returned AAUDIO_OK = 0
I don't know if this has any bearing on the audio data pointer but it is one of the only differences between the two up to the point the pixel crashes.
from oboe.
The difference between the Pixel code and the Samsung code is that the Pixel is using MMAP and the Samsung is using Legacy paths.
Your configuration seems very normal. But I have never seen this crash.
Are you using a std::shared_ptr when you open the stream?
https://github.com/google/oboe/blob/main/docs/FullGuide.md#open-the-stream
The only thing that occurs to me is that because this is a test, you may be creating an AudioStream, starting it and then the stream variable goes out of scope. That would cause the stream to be immediately closed and the buffer memory freed. There should be lock protection against this but maybe it is failing.
Please look in the log for "AAudioStream_close" before the crash.
If you are using a release version of Oboe, you may want to try the latest code from GitHub.
The main branch on GitHub is generally very stable.
from oboe.
Apologies for my late response I was a little busy on Friday
Are you using a std::shared_ptr when you open the stream?
I was not, instead, I was using the apparently deprecated oboe::ManagedStream
and openManagedStream()
. I have updated my code to use the std::shared_ptr instead
which has resolved the issue I was having on the pixel!
I really do appreciate your insights in debugging this! Thank you very much :)
Would you be open to a PR which introduced logging notifications when deprecated methods are in use? In retrospect, this might have helped me avoid this issue, and I would be happy to contribute if you agreed that this would be helpful.
from oboe.
Related Issues (20)
- Potential buffer overflows with some hard coded constants in samples
- OboeTester: need checkbox to disable call to setStreamControlByAttributes()
- Add IEC61937 support in OboeTester
- OboeTester display often too big for small phones
- Oboe Tester - Test Disconnect - Skip the test will leave a "Failed" message in status area
- OboeTester needs a Java echo test HOT 1
- OboeTester should have an option to test sample rates in the data paths test
- OboeTester latency analysis is too slow
- OboeTester Data Paths needs to test input with a session ID HOT 2
- OboeTester: setting ChannelMask should clear Channels HOT 1
- OpenSL ES using wrong stream type for RINGTONE
- ANR happens if plugin headset while do recording HOT 7
- getPeakLevel() called before setup(), logspam HOT 1
- Warning printed even when shared_ptr is used to call openStream HOT 1
- Trying to use oboe from binnaries but not working.. HOT 5
- 16-bit mono plays at wrong rate HOT 2
- No audio on Samsung Galaxy A21s when MMAP is enabled HOT 10
- Keep screen always on for test disconnect in OboeTester HOT 2
- TEST DISCONNECT doesn't work for USB device
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oboe.