Opened 14 years ago

Closed 14 years ago

Last modified 11 months ago

#2203 closed defect (worksforme)

ALL: Endianness sound problem

Reported by: SF/trilkk Owned by: fingolfin
Priority: normal Component: Ports
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 fingolfin, 14 years ago

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...

comment:2 by fingolfin, 14 years ago

Status: newpending

comment:3 by SF/trilkk, 14 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 SF/trilkk, 14 years ago

Status: pendingnew

comment:5 by SF/trilkk, 14 years ago

Status: newpending

comment:6 by SF/trilkk, 14 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 fingolfin, 14 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 fingolfin, 14 years ago

Owner: set to fingolfin
Resolution: invalid
Status: pendingnew
Summary: Endianness sound problemALL: Endianness sound problem

comment:9 by fingolfin, 14 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 fingolfin, 14 years ago

Resolution: invalidworksforme
Status: newpending

comment:11 by SF/sf-robot, 14 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 SF/sf-robot, 14 years ago

Status: pendingclosed

comment:13 by digitall, 11 months ago

Component: --Unset--Ports
Note: See TracTickets for help on using tickets.