Posts: 13,496
Threads: 305
Joined: Mar 2018
Reputation:
545
After re-reading the thread it appears that (1) the blues-alsa maintainer considers this a Pulsaudio issue, (2) the Pulseaudio maintainer has fixed it, and (3) there is a workaround (recompile bluez-alsa) for older Chromebooks that have the "bad" version of Pulseaudio.
I'm not seeing a reason to change the build recipe for bluez-alsa in moOde and risk regressions and support issues.
-Tim
Posts: 7
Threads: 1
Joined: Dec 2019
Reputation:
0
There still seems to be a misunderstanding.
This Chromebook is running the very latest release of ChromeOS. Unless you have confirmation from other ChromeOS users that everything is fine with *their* model, I think you must assume that moode currently works with _none_ of them.
Is there a way we could get current moode users that happen to have a Chromebook to test this out somehow? Call for testing?
Also, you mention that this might cause a regression, but I see no way this can happen at all. Please have a look at src/io.c in bluez-alsa where there's this check exactly 3x:
#if ENABLE_PAYLOADCHECK
if (rtp_header->paytype < 96) {
warn("Unsupported RTP payload type: %u", rtp_header->paytype);
continue;
}
#endif
How could not having this check regress anything? When removed, the quantity of accepted inputs is strictly higher than with the check.
Regards
Opi
Posts: 13,496
Threads: 305
Joined: Mar 2018
Reputation:
545
The payload check is there for a reason, prolly standards compliance, otherwise bluez-alsa maintainer would simply delete it. It defaults to "enabled" which works for the vast majority of bluetooth sources.
This is not a moOde issue. Google should include the fixed Pulseaudio in its updates to Chrome OS.
-Tim