Ogg Vorbis decode not working on FP4

My FP4 (20220413 stable) can’t play Oggs. Neither the built-in Music player, nor Opus 1, will play them. I thought at first it might be a transport problem, but having tried MicroSD card, HTTP download, and USB upload, it’s the same every way: MP3s play fine, OGGs don’t.

I found the thread at Ogg Vorbis audio decode not working in System and, not realising it was FP3-specific, resuscitated it. But I found the same workaround (VLC will play OGGs) which makes me wonder if it’s the same problem.

Does anyone else have trouble playing OGGs on a FP4?

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

1 Like

Hi. For me, same device and OS version, ogg files sound.

@jobal that’s most interesting, thank you. Which app are you using to play them?

VLC. Instead, CX File Explorer in-app player starts but don’t works.

1 Like

Ah, OK, thanks. That’s consistent with the reports in the other ticket, to which I alluded above, as is your observation that the built-in player(s) don’t work.

If I understand correctly, the hypothesis is that VLC contains its own rendering code; it’s only apps that leave it to the system renderer that can’t play OGGs. But I may have misunderstood.

This link gives some more general information on Media formats and Android.

@aibd thank you very much for that, but unless I misread it, it confirms that Ogg Vorbis is supposed to be natively supported - which is why it strikes me as odd that it doesn’t appear to be.

I did unearth the fixing commit for the FP3 in the old thread that moves the vorbis decode from hardware offload to software, this involves changing 4 config files. I think the same for FP4 will probably bring back proper system media lib support → https://review.lineageos.org/c/LineageOS/android_device_fairphone_FP3/+/293283

If you’re up for it you can test by elevating adb to root (developer options) if just editing the xml/conf files suffices to test the assumption. Not sure what the boardconfig makefile changes at buildtime. It’s an easy try.

1 Like

@tcecyk happy to try editing the three files via adb if you can point me at any kind of guide to same. Doesn’t need to be specific to these three files, just anything to help me get my head around using adb in that kind of way. Or indeed, at all!

as you’re on the stable build I’m not sure you can enable the dev-mode, or the adb-root specifically.

It’s behind tapping the build number in settings->about-phone 7 times. Then you go into the settings->system->Advanced…->developer options, scroll down to “android debugging”, enable the bridge and also enable “rooted debugging” one item below.

On your shell you run adb root and check with id if you’re on uid/gid 0/0

@tcecyk I can (and have) enabled dev mode, I’ve enabled “USB debugging” (is that what you mean by “the bridge”?), but the next item down is just “revoke USB debugging authorisations”. No mention of “rooted debugging” anywhere.

My wife has an FP4 also, which I think she hasn’t started setting up yet. I can try putting the dev version of /e/ on that, see if it lets me do as you’ve suggested?

yep, adb-root is likely to be a userdebug/user setting only. That’s why all those root-detectors trip on the build string being something-“user”

OK, will report back as and when I can get my wife’s handset off her to try it (I’m assuming that installing the dev build on my phone will wipe it). Thank you for all the help so far!

(you could also leave verification of the bug to the backlog. Flashing the dev build surely is disruptive, needs device unlock etc)

I rummaged in bugtrackers, the Calyx people have it fixed for the FP4 in their Android 12 branch in the same way it was done for FP3

https://review.calyxos.org/c/CalyxOS/device_fairphone_FP4/+/10393

so it might trickle down sometime to /e/ as soon as they switch to 11 or you could advertise for them in the gitlab backlog of /e/ to backport, see audio/audio_policy_configuration.xml · d7649fd2 · e / devices / android_device_fairphone_FP4 · GitLab

1 Like

Bearing in mind I’m no programmer, what would you recommend as the next step to most expeditiously get this change into stable? Should I register with the /e/ gitlab server and log a bug? Should I log the bug, but somewhere else? What works best?

I think starting an issue as you suggest is a very reasonable way forward. It certainly qualifies as an issue imho.

It might be accelerated if you had been able to pick up a workaround – or others can propose fixes in the knowledge you have the device and would be prepared to test.

And / or others with dev build FP4 may become interested in researching it further!

@aibd thanks, all excellent points. My understanding was that, as Calyx had confirmed the existence of the problem and fixed it for FP4 with the fix we used in the FP3 tree, little more confirmation was required - though I, too, would be delighted if somebody with the dev build could try the adb edits outlined by tcecyk above. If my wife lets me trash her handset and I can confirm it, I will of course report back.

I’ve tried to register an account for the /e/ GitLab, but it keeps kicking me back with “Email is not allowed for sign-up. Please use your regular email address.” despite being given four manifestly-valid email addresses. I’ll wait a bit and see if I can sign up later.

This is not the preferred option, the second issue can be fixed.

Getting an error message – gitlab login

I thought the two weren’t mutually-exclusive, ie, both “further confirmation” and “formal reporting” were desirable. That said, I have emailed the support people as your link suggested (many thanks for that).

And I suspect it is little pain to reinstall the dev build on my wife’s handset as both our phones are less than a week old, and she’s done absolutely no configuration of hers yet (it’s still at the post-installation “Start” screen). But if this is not so I will of course not be upsetting her!