Tests for pyglet.media.synthesis, and possibly sound synthesis itself, fail on big-endian architectures. See the upstream issue for details.
Pyglet can synthesize simple sounds, which are meant for immediate playback rather than saving to a file. I do not know if the failure is a bad test or if bad data is passed to the sound system. Is there a way I can listen to the sound generated and played on a big-endian machine?
I don't think this will ever have enough priority for me, but if anyone wants to take it, go ahead.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I was alerted to this bug because of bug 2006529; sympy depends on pyglet, so now sympy cannot be installed on s390x. I would like to try to fix this bug. I have shell access to an s390x machine, thanks to Dan Horák. On that machine, I installed flac and then flac-converted the WAV files in tests/data/media. The flac binary ran without error. I then copied the flac files back to my little endian x86_64 machine, and played each original WAV file, followed immediately by the corresponding flac. The sounds are identical in each case. This suggests to me that the test files are correct, and that the synthesis code needs to generate bytes in little endian order, regardless of host architecture. This theory is bolstered by claims that files that start with RIFF (as those generated by pyglet do) are little endian. For example: https://stackoverflow.com/questions/1111539/is-the-endianness-of-format-params-guaranteed-in-riff-wav-files https://en.wikipedia.org/wiki/Resource_Interchange_File_Format I cannot test this theory directly, as I also do not have direct access to s390x hardware, but this seems plausible. Does anybody object to an attempt to change the synthesis code, on the assumption that the test files are correct?
See https://github.com/pyglet/pyglet/pull/469 for a possible fix. The tests all pass with that commit.
FEDORA-2021-82279f584d has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-82279f584d
FEDORA-2021-82279f584d has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-8e0dc324b8 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8e0dc324b8
FEDORA-2021-8e0dc324b8 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8e0dc324b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8e0dc324b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8e0dc324b8 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.