OSX (PPC) build and CD32 audio tracks

Hello,
it seems that nobody has yet reported this but I found that CD-audio tracks on CD32 titles does not play correctly on PPC OSX build of FS-UAE including the latest Dev release.
The CD32 titles I have tested are verified rips in the form of the usual CUE/ISO/WAV pattern in the same folder named as the original.
They sounds beatifully on Intel OSX build but not on PPC machines where all the CDDA tracks are played as a loud white noise from start to end at a costant volume, no music is recognizeable inside: i mean it is not a noise layered to music, the noise is the ONLY audible sound.
The sound from Amiga chipset instead is clean and correctly reproduced.
My thought is that since the CDDA tracks are stored in WAV format they should be played as a stream so they should be almost independent from the computation power of the host where the emulator run (but I am not a programmer so I could be wrong here).

P.S.: A little note for G4 and G5 users: the builds made on a G4 machine will not work on a G5 and vice-versa (same OSX, MacPorts tools and SDL framework installed).

A little update: the problem with PPC build (OSX 10.5.8) and CDDA audio tracks seems related to a general audio samples handling because also the floppy drives "click" sound emulation is broken, instead an hissing sound (white noise) is emitted.
I did notice this since the very first PPC build but having disabled this feature in the config file I did not give it much importance until I have tried some CD32 titles.
I am confident that fixing the audio samples playback of floppy drive sounds would also fix the CDDA tracks in PPC emulation.

[FrodeSolheim]

I don't think these two issues are directly related by code, but is probably exactly the same problem: That the 16-bit samples are not byte-swapped for PPC / big-ending computers.

I haven't checked, but it's a fair assumption. I should be able to create a patch for someone to try out...

I agree, one of the most common issue in intel/PPC builds is exactly the byte order between big and little endian. If you agree I could test the patch on my G4 machine, maybe the sound will be a bit stuttering but at least recognizable :-)

[FrodeSolheim]

Try the following patch:

diff --git a/fs-uae/src/driveclick.cpp b/fs-uae/src/driveclick.cpp
index 48e610b..5ecfb15 100644
--- a/fs-uae/src/driveclick.cpp
+++ b/fs-uae/src/driveclick.cpp
@@ -50,7 +50,15 @@ uae_s16 *decodewav (uae_u8 *s, int *lenp)
                        s += 4;
                        len = s[0] | (s[1] << 8) | (s[2] << 16) | (s[3] << 24);
                        dst = xmalloc (uae_s16, len / 2);
+#ifdef __BIG_ENDIAN__
+                       int8_t *dst8 = (int8_t *) dst;
+                       for (int i = 0; i < len; i += 2) {
+                               dst8[i] = s[i + 1];
+                               dst8[i + 1] = s[i];
+                       }
+#else
                        memcpy (dst, s + 4, len);
+#endif
                        *lenp = len / 2;
                        return dst;
                }
diff --git a/fs-uae/src/od-fs/cda_play.cpp b/fs-uae/src/od-fs/cda_play.cpp
index 92540c5..d9c5eee 100644
--- a/fs-uae/src/od-fs/cda_play.cpp
+++ b/fs-uae/src/od-fs/cda_play.cpp
@@ -111,7 +111,17 @@ bool cda_audio::play(int bufnum) {
     }
 
     if (g_audio_callback) {
-        buffer_ids[bufnum] = g_audio_callback(3, p, num_sectors * 2352);
+        int len = num_sectors * 2352;
+#ifdef __BIG_ENDIAN__
+        int8_t *d = (int8_t *) p;
+        int8_t temp = 0;
+        for (int i = 0; i < len; i += 2) {
+            temp = d[i + 1];
+            d[i + 1] = d[i];
+            d[i] = temp;
+        }
+#endif
+        buffer_ids[bufnum] = g_audio_callback(3, p, len);
     }
     else {
         buffer_ids[bufnum] = 0;

[SnakeCoils]

I have tried and compiled the 2.5.1 development release directly and it worked like a charm! :-) Succesfully tested on the following CD32 games:

- Super Stardust
- Pinball Fantasies
- Banshee

It was like playing with a real CD32! Amazing!

[amigafreak68k]

Could you please share your binary in the Zone?

[SnakeCoils]

Sure, I have just uploaded it in The Zone area :-)
The only thing missing from this binary is the libfs-capsimage library because at present I've not yet understood if there is a "clean" way to put it in the App package because the source of this library does not compile under PPC... :-(
To make the FS-UAE binary I commented out the line in the makefile where the library is copied, in this way the build process is succesfully, otherwise it will stop during the "fixing" process of the various parts to include.

[FrodeSolheim]

If there was a question in there...: Yes, you must include a PPC-compiled version if it is to be included, but FS-UAE will work fine without (just missing support for .ipf files).

Judging by http://www.softpres.org/download, it looks like it should be compilable for PPC. Copying and renaming the library (v4.2) from "Mac OS-X 10.4 Framework (Universal)" (http://www.softpres.org/download) *may* also work.

[SnakeCoils]

Ok, after googling around and few experiments I finally have done a clean ppc build of FS-UAE 2.5.1 development :-)
First, the Libfs-capsimage 4.2 archive doesn't build on command line, the "make" command generates this output:

power-mac-g4-di-snakecoils:libfs-capsimage-4.2 snakecoils$ make
cd CAPSImage && ./configure
checking build system type... powerpc-apple-darwin9.8.0
checking host system type... powerpc-apple-darwin9.8.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in `/Users/snakecoils/Downloads/libfs-capsimage-4.2/CAPSImage':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make: *** [all] Error 1

But inside the CAPSimage folder I have discovered an Xcode project, changing the type of build target I am been able to generate a PPC-only CAPSimage framework.
In first place I put this in the System/Framework/ folder but the FS-UAE Makefile script didn't found it so to allow the build process to complete I have to create a secondary Framework folder in my home/library/ where I placed the CAPSImage.Framework there and this time worked.
The universal binary package from the site you pointed me didn't work, I suspect because of its "ppc-intel" nature, it seems your fixing script dislike the i386 part and refuse to handle it believing it is not ppc compliant but I am absolutely not a programmer, all of above is pure speculation :-)