Frank Wang comments

Results 6 comments of


                                            Frank Wang

The client receives the callback onErrorAfterClose from oboe even if the audio stream is closed. [ Same as Issue 1578]

> @FeiWang888 - I also recommend using Oboe 1.6.1. > > What is the latest version of Android where you have seen this happen? The Oboe version we use is...

The client receives the callback onErrorAfterClose from oboe even if the audio stream is closed. [ Same as Issue 1578]

Thanks for reviewing this issue again. Here are some feedbacks. @philburk 1. According to the log, it is a possible sequence of events you mentioned. 2. "You asked how an...

The client receives the callback onErrorAfterClose from oboe even if the audio stream is closed. [ Same as Issue 1578]

@philburk I recommend that the thread checks the audio stream state before sending the error callback. using shared_ptr for callbacks does not guarantee the instance for callbacks will not destroy....

The client receives the callback onErrorAfterClose from oboe even if the audio stream is closed. [ Same as Issue 1578]

I understand your point about the pointer. However, in this case, it will make sense if the audio stream is in the closed state, there is no reason to invoke...

Help, two new types crash issue(oboe_aaudio_error_thread_proc_shared) showing.

@philburk please take a look. FYI. It is hard to reproduce the issue. We cannot see the issue on our devices, so don't have the client log.

Help, two new types crash issue(oboe_aaudio_error_thread_proc_shared) showing.

We will reset the shared pointer of the stream (std::shared_ptr) after invoking stopping and closing the steam. "Do you think this may be happening when headsets are plugged in or...