#2203 closed defect (worksforme)
ALL: Endianness sound problem
| Reported by: | SF/trilkk | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Ports |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
When playing the games on PowerPC G4 running Linux, all sound is garbled. I examined the source code and found out the problem being no endianness checks in the mixer code.
Now, the strange thing is that before 0.7.1 sound worked just fine. The glitches began when upgrading to the current version. Either the sound code is completely changed, or the endianness check has been removed (why in the name of god?).
I was able to fix the problem for me by modifying the SoundMixer::mix method and adding implicit byte swaps at the end of the code (after each channel has been mixed).
// This way for(int i = 0; i < len; i++) { int8 *dst = (int8*)(&buf[i * 2]); int16 l = buf[i * 2], r = buf[i * 2 + 1]; dst[0] = l & 0xFF; dst[1] = l >> 8; dst[2] = r & 0xFF; dst[3] = r >> 8; }
Now, as we can see this piece of code is bullshit. Although it makes sound play ok, I don't know about your methods about checking the endianness nor I do know in which point would you like the check to be done.
Please fix this in an elegant manner or provide me some information on how it should be done.
Ticket imported from: #1294413. Ticket imported from: bugs/2203.
Change History (13)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
| Status: | new → pending |
|---|
comment:3 by , 19 years ago
I'll provide the specks. All those that I can.
I'm running Linux on a Genesi Pegasos-II (G4). That should qualify as a big-endian machine. When I install the package from the debian archive or the sources, I will simply get very loud static when starting up - for example - Beneath a Steel Sky. If anyone in the development team has a Pegasos, I hope (s)he can replicate this occurrance.
Now, the code I supplied fixes this, but as said, it is stupid. Also, it is really very strange, as after the mixer callback SoundMixer::mix completes it's run, the data in the output buffer is in the opposite endian mode of what it should be.
I don't know about the input streams, but I suppose SoundMixer::mix affects all outgoing audio, and after adding that piece of bubblegum, all audio sounds ok.
If you would be so kind as to specify where exactly do you make the endian checks, I could try to debug it a bit myself (should there be no other options). I'm using the SDL interface.
comment:4 by , 19 years ago
| Status: | pending → new |
|---|
comment:5 by , 19 years ago
| Status: | new → pending |
|---|
comment:6 by , 19 years ago
I'll provide the specks. All those that I can.
I'm running Linux on a Genesi Pegasos-II (G4). That should qualify as a big-endian machine. When I install the package from the debian archive or the sources, I will simply get very loud static when starting up - for example - Beneath a Steel Sky. If anyone in the development team has a Pegasos, I hope (s)he can replicate this occurrance.
Now, the code I supplied fixes this, but as said, it is stupid. Also, it is really very strange, as after the mixer callback SoundMixer::mix completes it's run, the data in the output buffer is in the opposite endian mode of what it should be.
I don't know about the input streams, but I suppose SoundMixer::mix affects all outgoing audio, and after adding that piece of bubblegum, all audio sounds ok.
If you would be so kind as to specify where exactly do you make the endian checks, I could try to debug it a bit myself (should there be no other options). I'm using the SDL interface.
comment:7 by , 19 years ago
Your code is just a workaround for the problem. It doesn't solve it. The mixer is already fully endian aware and safe. It was designed from ground up with endian issues in mind. In fact, the mixer *always* gets sound data in the native endianess. It is up to input streams to provide the data in the correct format (which is native endian 16 bit signed audio data).
You should contact whoever made that binary. Chances are that they somehow got a screwed up built which was set to little endian, for whatever reasons. Normally the configure script auto-detects the endianess of your system and compiles accordingly. If for example they did a cross compile incorrectly, e.g. on an intel box, that might be the cause of the problems. Hard to tell.
The problem isn't on our side, however. We daily test ScummVM on a
large variety of target CPUs and systems, and it works fine everywhere
else...
comment:8 by , 19 years ago
| Owner: | set to |
|---|---|
| Resolution: | → invalid |
| Status: | pending → new |
| Summary: | Endianness sound problem → ALL: Endianness sound problem |
comment:9 by , 19 years ago
As stated before, the problem isn't reproducible anywhere.
If you want to give it a try, the endian checks are performed by the configure script, and cause SCUMM_BIG_ENDIAN to be #defined in config.h.
That flag in turn is checked in common/endian.h to properly define lots of functions and macros for endian safe data access.
comment:10 by , 19 years ago
| Resolution: | invalid → worksforme |
|---|---|
| Status: | new → pending |
comment:11 by , 19 years ago
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
comment:12 by , 19 years ago
| Status: | pending → closed |
|---|
comment:13 by , 6 years ago
| Component: | --Unset-- → Ports |
|---|
That's wrong, The mixer contains no endian bugs. It was in fact written by somebody working on a big endian (G4) machine, i.e. *me* :-)
Whatever (endian) problems you are seeing, they are *not* in the mixer.
Maybe one of the input stream classes is buggy. Since you do not give us any information on how to reproduce this "bug", nothing we can do about it for now...