For a different perspective, I tried running the same version of Quicktime in VirtualPC running Windows 2000. VirtualPC is a PC emulator originally made by Connectix. To my surprise, the audio also drops. It seems to drop even more than for QEMU! Realplayer was able to handle the MP3 a lot better. During the Realplayer MP3 playback test, CPU usage was mostly around the 85% to 90%. For Quicktime, it was at 100% and the audio was completely dropped during that time. I did this test on an 11 year hold iMac G5.

When I tried Quicktime on Windows XP running in VirtualBox, the audio played perfectly. The host was a 7 year old Core 2 Duo.

Now I'm wondering about what Apple knows. I know that the x86 processor does have hidden registers that hackers found out about. I wonder if Apple decided to use them, but the emulators didn't. Could IBM have made hidden registers in their PowerPC product that Apple was only told about? This could be the assumption about hardware Apple is making.

Tested using 2.7 and 2.8pre; haven't bothered testing anything later. Tested using the vga patch version with sungem networking.

We were using MacBench to test the FPU back when we first started looking at this; agreed that this doesn't really tell us all that much. When using the monitor, we saw way more FPU calls than I at least was expecting.

I haven't checked yet to see whether we're always handling the FPU calls as expected. Logging all exceptions might be useful for isolating any expected results from undocumented calls. Stepping through when the volume peaks might also be useful.

Could IBM have made hidden registers in their PowerPC product that Apple was only told about? This could be the assumption about hardware Apple is making.

Apple was a co-designer with IBM and Motorola; original chips were manufactured by Motorola, with only the later ones being IBM. Since this didn't happen on the IBM chips (I had a G5), it seems that whatever they were doing was at least consistent across the implementations.

HOWEVER, the Quicktime engine for Intel/Windows was itself running inside a WINE-like layer; Quicktime for Windows (6 and earlier) was actually a cross-compiled Quicktime for Mac inside a virtual environment that presented the Mac toolbox calls.

And anyone who ever used Quicktime for Windows knows how horrible that experience was. There was the delay while the virtual environment booted up, and then the CPU was pegged while doing the audio processing. So it was doing something that didn't cross compile to x86 all that well. It's possible that we're running up against the same issue here; that Quicktime (and the audio toolbox calls) are making use of PPC functions/relationships that just don't translate well into a pipelined x86 architecture.

Could IBM have made hidden registers in their PowerPC product that Apple was only told about? This could be the assumption about hardware Apple is making.

Apple was a co-designer with IBM and Motorola; original chips were manufactured by Motorola, with only the later ones being IBM. Since this didn't happen on the IBM chips (I had a G5), it seems that whatever they were doing was at least consistent across the implementations.

HOWEVER, the Quicktime engine for Intel/Windows was itself running inside a WINE-like layer; Quicktime for Windows (6 and earlier) was actually a cross-compiled Quicktime for Mac inside a virtual environment that presented the Mac toolbox calls.

And anyone who ever used Quicktime for Windows knows how horrible that experience was. There was the delay while the virtual environment booted up, and then the CPU was pegged while doing the audio processing. So it was doing something that didn't cross compile to x86 all that well. It's possible that we're running up against the same issue here; that Quicktime (and the audio toolbox calls) are making use of PPC functions/relationships that just don't translate well into a pipelined x86 architecture.

Your knowledge of Quicktime is impressive.

A while ago there was a lot of work being done to make OpenBIOS boot Mac OS 9. Someone on this forum referred to Apple's interesting forth code as "anti-emulation". I'm beginning to wonder if they do have code in their programs that prevent or discourage its use in an emulator. The code could be as simple as checking to see if the CPU is made by Motorola or IBM. If it isn't, make the user's life difficult.

I did another test were I ran this tiny MP3 decoder (http://keyj.emphy.de/files/projects/minimp3.tar.gz) in Windows 2000 in qemu-system-i386. The MP3 playback was excellent. Its source code shows it using many floating point instructions. Here is a little sample:

A while ago I post my super cocoa.m file with the pasting feature. This feature didn't appear to work well. I found out that using the USB keyboard makes it work way better than the ADB keyboard. I was able to paste 800 numbers without a single mistake.

It actually played an MP3 well in QEMU. It took me a while, but I finally figured out how to make it play in Mac OS 9.2. I heard 13 seconds of an MP3 play well. I think due to bugs with the OHCI USB controller, the audio stopped playing.

Found a program that can actually test PowerPC instructions inside of QEMU. It is called risu. It works by first running on a real PowerPC, collecting data on how each tested instruction effects all the registers. Then you "replay" this information inside of QEMU and are told of any differences encountered.

would you need some tests on a G5? I have a G5 iMac available to run it if needed.

Thank you for the offer. Having a lot of different PowerPC chips to test might help us understand what is wrong with QEMU. Would anyone have a PowerPC G4 based Mac they could test Risu on when it is ready?