Replies: 1 comment 1 reply
-
Thanks. I don't have a way to reproduce this. I've pushed an experimental workaround to the dev branch. Are you able to give that a try? You'll need to add this to your device config or else the workaround won't be used: deviceConfig.aaudio.enableCompatibilityWorkarounds = MA_TRUE; This change will simply not set the data callback size. I think that's what Oboe is doing to work around it. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
There's a possible bug that was also reported in Oboe:
Several days ago I picked up a used Samsung Galaxy A10s for testing. It generated an error when I set the period size:
maybeConvertDeviceData() conversion size 1024 too large for buffer 512
I apologize for the sketchy details that follow, but It was a hectic time when all of this was going on. The logs are below. I didn't get a chance to capture pertinent info around the android version and API levels because the phone did an auto update. I think it was Android 10 and I think I had a simple duplex example running.
I tried increasing the period size from 512 to 1024 and got the following error, which is double the buffer size of the original error:
Abort message: 'maybeConvertDeviceData() conversion size 2048 too large for buffer 1024'
I search around and saw that people were complaining about the error in Oboe. The Oboe team did something to fix it (something about using a proxy for callback size adapter): Crash when setFramesPerCallback(#frames) is used for input stream #778
When my phone updated the android version, this problem went away.
I wouldn't mind factory resetting the phone to try to get the exact versions to reproduce it, if necessary.
I just realized that there is a build fingerprint in the logs for the phone, when I search it, I get this version info: https://samfw.com/firmware/SM-A107F/MID/A107FXXU8BUF1
Beta Was this translation helpful? Give feedback.
All reactions