-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification on thread safety #32
Comments
Thanks for asking. The Thread Safety section is pretty confusing. Some of it is inaccurate. Oboe does use some mutexes for non-time-critical functions like start()/stop(). There are some things you CAN do.
There are some things you CANNOT do.
In general you should only modify the stream from one application thread. From the callback methods try to only use get*() methods. Please ask more questions. When we have an explanation that makes sense then we will update the docs. |
Thanks, what about |
You can safely call getBufferSizeInFrames() from as many threads as you want. You may be sampling a changing value. So only use the information for non-critical purposes, such as a fullness display. Only call setBufferSizeInFrames() from one thread. So if latency tuning is active in the callback, do not call it from the application. |
Thanks. As far as I understand, |
Thinking aloud and off-topic - wouldn't it be good if LatencyTuner had a mode where it started from the maximum buffer size and worked down for some initial period of time like a minute, stopping lowering when it encounters drop-outs, then worked like it does currently, raising back up. That way user wouldn't be presented with lots of static when first opening an app, which can happen if there is heavy CPU load. I suppose this could be implemented in application too, but more suitable within LatencyTuner. |
Not necessarily. It depends on the latency tuning algorithm. Suppose a glitch was caused by some transient activity. After a while it may be safe to lower the latency again. Some apps might be willing to risk a glitch in order to minimize latency. Some apps will not want to take that risk. This is why we left the tuning out of the OS. Apps can decide. An app can calculate output buffer fullness as framesWritten minus framesRead.
Excellent. We hoped that apps would do that.
The behavior can vary a lot by device.
That could be a good strategy for some apps. But some apps, synthesizers for example, are often silent for a few seconds before the user starts playing. That is a good time for the LatencyTuner to glitch because the glitches are inaudible. We encourage app developers to customize the LatencyTuner for their own purposes. And please share your experience. Also please let use know if you post any apps in the Play Store. We can then use it for testing the OS. |
I was planning on rolling out update https://play.google.com/store/apps/details?id=com.smp.musicspeed with Oboe as the default sound output this weekend. I was a little hesitant because it is developer preview, but it seems to be behaving perfectly so far. My use is simple, only an output stream. I wanted to start using AAudio as soon as possible. Do you think it is relatively safe to use for production? I was thinking the preview aspects of it would be obvious things like unimplemented functions. |
Until you filed #40, I would have said yes. We are now investigating that as a high priority. Let's leave this open until we clarify the thread safety issues in the docs. |
Any update here @philburk? |
#40 has been addressed by not using AAudio on 8.0. We need to add the restrictions and caveats from this discussion to the autodocs for AudioStreamCallback. Then reference those restrictions in AudioStreamBuilder::setCallback() docs. Then we can close this. |
AI: Clarify this in the docs |
Phil to update docs. Don to regenerate API reference. |
For example, do not stop() or write() a stream from the callback. Issue #32
Docs have been updated, specifically here: file:///Users/donturner/Code/workspace-android/oboe/docs/reference/classoboe_1_1_audio_stream_callback.html |
It seems a little confusing to me from the guide what is permissible as far as thread safety.
Does this mean I can be writing data to the audioData void* in the callback while simultaneously calling
requestPause()
,requestStop()
,close()
in some other function on another thread?`
The text was updated successfully, but these errors were encountered: