Android 12 which is API level 31 or 32 => we use AAudio. A regression from bug 1938570 is likely. Marking it tentatively. I cannot reproduce on my Galaxy S22. 134 used significantly more buffering, something like 300ms. Now we use a 50ms AAudio buffer for a 100ms callback. This means we put 100ms into the callback, which then fills the 50ms AAudio buffer and is blocked until empty. When the callback buffer becomes empty it gets dispatched again to the content process to get more data, and it has the 50ms worth of data in the AAudio buffer to return. If it doesn't, we underrun. I imagine bug 1931080 would help here but would need a profile to verify the root cause. Unfortunately getting a profile on Android involves connecting it to a computer and controlling it there. I hope we can find someone to reproduce this internally. We could try a simpler verification if either reporter is up for it: - Install Firefox Nightly - Go to about:config (not available on release, sorry) - Click the plus sign to create a new pref - Name: `media.cubeb_latency_playback_ms` - Type: `Integer` - Value: 200 - Click "Create" - We'll now use a 100ms AAudio buffer and 200ms callback buffer, which should be plenty. - Kill the app and relaunch it, optionally verifying that the pref is still there. - Try to reproduce. Did this improve the situation? Thanks in advance!
Bug 1947917 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Android 12 which is API level 31 or 32 => we use AAudio. A regression from bug 1938570 is likely. Marking it tentatively. I cannot reproduce on my Galaxy S22. 134 used significantly more buffering, something like 300ms. Now we use a 50ms AAudio buffer for a 100ms callback. This means we put 100ms into the callback, which then fills the 50ms AAudio buffer and is blocked until empty. When the callback buffer becomes empty it gets dispatched again to the content process to get more data, and it has the 50ms worth of data in the AAudio buffer to return. If it doesn't, we underrun. I imagine bug 1931080 would help here but would need a profile to verify the root cause. Unfortunately getting a profile on Android involves connecting it to a computer and controlling it there. I hope we can find someone to reproduce this internally. We could try a simpler verification if either reporter is up for it: - Install Firefox Nightly - Go to about:config (not available on release, sorry) - Click the plus sign to create a new pref - Name: `media.cubeb_latency_playback_ms` - Type: `Integer` - Value: `200` - Click "Create" - We'll now use a 100ms AAudio buffer and 200ms callback buffer, which should be plenty. - Kill the app and relaunch it, optionally verifying that the pref is still there. - Try to reproduce. Did this improve the situation? Thanks in advance!