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.

I tested:
USB-Audio (not screamer)
qemu-system-ppc (not i386)
Guest OS: 9.2.1 (also tested 9.0.4, 9.1, 10.0, 10.1, 10.2, 10.3, 10.4 and 10.5, but 9.2.1 was the most pronounced).

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.

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.

There is a gsoc project defined dealing with audio. Perhaps someone takes it? It mentions patching qemu with a old patch set and using gstreamer as backend.
http://wiki.qemu-project.org/Google_Sum ... io_backend

I tried to build from the repository containing the old code, but it failed:
https://github.com/DirtYiCE/qemu

And there are some patches lined up that enable playback through SDL on OSX:
http://lists.nongnu.org/archive/html/qe ... 00134.html

Best,
Cat_7

Thank you for this information. Should adding Mac OS 8.5 support be added to Google Summer of Code 2017?

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:

static INLINE double __declspec(naked) libc_pow(double b, double e) { __asm {
fld qword ptr [esp+12]
fld qword ptr [esp+4]
fyl2x
// following is a copy of libc_exp:
fst st(1)
frndint
fxch
fsub st(0), st(1)
f2xm1
fld1
fadd
fscale
ret
} }

We still don't fully know what Quicktime is doing or why it is failing during MP3 playback. The only way we could is by reverse engineering it.

Does all playback use QuickTime? Perhaps there is an mp3 player not using it?
http://www.everymac.com/mac-answers/mac ... tunes.html

Best,
Cat_7

I remember a 68k mp3 player for Mac OS that was purely dependent on FPU and didn't use Qucktime (which didn't support mpeg 2 at that point). I'll look and see if I can find it.

Soundapp (Fat) could play MP3's on 68k Macs.

Are you sure? I thought it used the PPC quicktime plugin for that. I never got SoundApp to play MP3s on my 68k Mac.

I guess you're right, SoundApp's website says it needs a PPC cpu for Mp3's.

There is MpegDec, for the 68040:

-Requirements:

68040 or PPC.
fpu not required for 68040 version.
SoundManager 3.0 (SoundManager 3.2.1 and higher recommended).
MacOS 7.1 with Drag and Drop 1.1 and Finder 7.1.3
(MacOS 7.5 and higher recommended).

http://www.applefritter.com/node/14768

Really works good in BasiliskII.

MpegDec is the one I was thinking of -- I think it may be the only 68k MP3 player (there are a few others that can convert, but can't play in real-time).

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.

https://git.linaro.org/people/peter.may ... git/about/

Wow! That's a great find!

[edit] Any chance you could compile a copy? I'd like to run it on my G4s and make the resulting data available for others to use when testing qemu.

Right now it doesn't seem to compatible with 32 bit PowerPC CPUs. I will try to change this.

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?

I could offer running it on a G3 and a PM 7500/100 (not sure which chip the latter one uses, but I doubt that one would be of any help anyway).

I can test it on a G4 under 10.4.11 and 10.5.9 Server.

Besides the G5 iMac I also have a G3 iMac to test on. But no G4 I think.

Hi, I was wondering if any of you would be interested in helping me test out my new front-end to QEMU I call MacQEMU. Here's a picture:



Here's the download link: http://www.mediafire.com/file/0v663z21r ... beta_1.zip

Please let me know what you think.

System Requirements:
- Mac OS 10.6 or higher
- Python 2.7 or higher
- TK framework 8.5 or higher
- x86-64 processor

It comes with both qemu-system-ppc and qemu-system-i386 version 2.8.0. Hopefully this will make QEMU a lot more user-friendly.

Hi,

MacQemu tells me it requires 10.4 or higher and then detects my version as 10.11.4.
I can only click OK. Nothing else happens.

Best,
Cat_7

Thank you for finding this bug and testing out MacQEMU. I will make a quick beta 2 version that fixes this problem shortly.