Skip to content
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

Update DuplexCallback.h in fxlab #2136

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

dipak140
Copy link

In cases where the stream does not start immediately when starting the app, the audio stream is stopped immediately, which means the demo does not work. This if statement is unnecessary since any errors will be handled by ErrorCallback.

In cases where the stream does not start immediately when running the app, the audio stream is stopped immediately, which means the demo does not work. This if statement is unnecessary.
@philburk
Copy link
Collaborator

@dipak140 - Is the read() returning an error?!
What is the error code?
What device is this happening on?

Maybe we could start with a bug report. The fix may be needed in Oboe.

@dipak140
Copy link
Author

@philburk There was no error, the read just returned null at the beginning, which meant the stream was requested to close immediately, and the data callback stopped. This behaviour is unfortunately not replicable easily, and even i didn't catch it at first since it worked fine on my device (Samsung A12). It did not work on Realme, which was caught later on.

Secondly, the if statement should be added before the read, if i am not wrong?

I am also skeptical about the need of stopping the stream altogether if the read is unsuccessful, since the start request can take time and the onAudioReady callback would be called regardless. Please do correct me if this assumption is wrong. Will raise a bug report regardless.

Additionally, the app uses managed stream which is deprecated from what i checked, so would you be open to a Patch to replace it with audioStream?

@robertwu1
Copy link
Collaborator

The issue is that the ErrorCallback only is registered for the output stream currently in the sample. If remove the line of code in this PR, if the input fails, there will be no clues.

There is a line where we wait at most 500 seconds to start a stream. Can you try increasing this to a large number on the Realme? Thanks!

Perhaps the real change is to increase this timeout.

@robertwu1
Copy link
Collaborator

We're open to the patch to remove the managed stream. Thanks!

@philburk
Copy link
Collaborator

There was no error, the read just returned null at the beginning,

If the result.value() is zero then that just mens there was no data available.
That can happen when the streams are stabilizing.

We should probably use the FullDuplexStream class in the fxlab example.

@philburk philburk changed the title Update DuplexCallback.h Update DuplexCallback.h in fxlab Jan 14, 2025
@dipak140
Copy link
Author

The LiveEffect sample uses FullDuplexStream, I can raise a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants