Feedback on RC1 (r755)

[jonof]

I've just grabbed the 755 and 764 revisions to upgrade the 632 version I had before and both of the new versions are exhibiting stutters when FLAC or MP3 is being played from my network server (100mbit Ethernet via AFP). 632 does not have the problem under the same conditions.

Jonathon

[sbooth]

I've just grabbed the 755 and 764 revisions to upgrade the 632 version I had before and both of the new versions are exhibiting stutters when FLAC or MP3 is being played from my network server (100mbit Ethernet via AFP). 632 does not have the problem under the same conditions.

When you say stutters, do you mean actual stutters/skips/dropouts during playback, or gaps between the tracks?

[jonof]

I mean the sound drops out during playback with a burst of network traffic for the next block of data.

Jonathon

[sbooth]

I mean the sound drops out during playback with a burst of network traffic for the next block of data.

Are these 16-bit/44.1 FLACs?

[jonof]

Yes, they are. Same for the MP3s.

Jonathon

[sbooth]

Yes, they are. Same for the MP3s.

I've split this into a separate thread.

[SciFi]

Results of my repeated tests with your samples (orchestral music):

FLAC = gaps between every track

MP3-CBR = no gaps noticeable at all

MP3-VBR = gaps between/after tracks 15 & 16 (yes tried several times), not noticeable on other tracks

WavPack = gaps between every track

I'm not sure how to explain this. I've listened to all these files/formats literally a hundred times, and I've even saved the audio output to a file instead of piping it to an output device. This goes for FLAC, even when I seek back and forth several times.

I'm not running a high horsepower machine either- a PowerBook G4.

In any case, there is an audible click about 1.5-2 seconds into track 16. This is a defect in the source material, and could explain the issue you reported with the VBR MP3s.

For FLAC and WavPack I'm at a loss. I will see what changed from r722 onward, but I don't think it was much to do with decoding. I did change things so that FLAC (and every other format) is converted to 32-bit floating point before being sent to the output device, but this would not affect gapless at all.

This is gettin' weird. I built your r775 myself here, but with the tweaks I'll quote below (diffs to the xcodeproj settings).

And all of your samples played just fine. (yes I can hear the glitch on track 16 in all samples now )

What I need to do next is build the frameworks with the same kind of tweaks (I'm just using your prebuilt 20070503 archive for now). I have the standard *ix cmd-line & static & dylibs built with these tweaks, but I've never been able to figure out how to do them Apple's way as in frameworks.

The tweaks are painstakenly tested based on Apple's -fast switch, which by itself will cause many projects to miscompile (for ex. -fast causes parchive.sf.net aka par2 to usually not be able to find header data inside the .par2 files). So I've narrowed the set of options down to what you see in the diff below. I also added -ftree-vectorize but sometimes it will miscompile object code, too, and also can cause Apple's gcc-4.0.1 to abort while compiling (mplayer has a module that does it every time, with such reliability that I ought to use it as a bug-report to send to Apple).

Okay here's the tweaks to the xcodeproj settings:

Code: Select all

Index: Play.xcodeproj/project.pbxproj
===================================================================
--- Play.xcodeproj/project.pbxproj	(revision 775)
+++ Play.xcodeproj/project.pbxproj	(working copy)
@@ -2177,8 +2177,68 @@
 		C01FCF5008A954540054247B /* Release */ = {
 			isa = XCBuildConfiguration;
 			buildSettings = {
+				GCC_ALTIVEC_EXTENSIONS = YES;
+				GCC_AUTO_VECTORIZATION = YES;
+				GCC_FAST_MATH = YES;
+				GCC_FAST_OBJC_DISPATCH = YES;
+				GCC_MODEL_PPC64 = YES;
+				GCC_MODEL_TUNING = G5;
+				GCC_STRICT_ALIASING = YES;
 				GCC_WARN_ABOUT_RETURN_TYPE = YES;
 				GCC_WARN_UNUSED_VARIABLE = YES;
+				OTHER_CFLAGS = (
+					"-Os",
+					"-floop-optimize2",
+					"-fbranch-target-load-optimize2",
+					"-Wall",
+					"-ftree-vectorize",
+					"-ftree-vectorizer-verbose=1",
+					"-falign-loops-max-skip=15",
+					"-falign-jumps-max-skip=15",
+					"-falign-loops=16",
+					"-falign-jumps=16",
+					"-falign-functions=16",
+					"-fsched-interblock",
+					"-Wstrict-aliasing=2",
+					"-fexpensive-optimizations",
+					"-foptimize-register-move",
+					"-fno-enforce-eh-specs",
+					"-fgcse",
+					"-fgcse-lm",
+					"-fgcse-sm",
+					"-fgcse-las",
+					"-fgcse-after-reload",
+					"-ftree-loop-linear",
+					"-ftree-loop-im",
+					"-ftree-loop-ivcanon",
+					"-fivopts",
+					"-ftracer",
+					"-fvariable-expansion-in-unroller",
+					"-fprefetch-loop-arrays",
+					"-freorder-blocks",
+					"-funit-at-a-time",
+					"-fweb",
+					"-fno-math-errno",
+					"-frename-registers",
+					"--param",
+					"max-gcse-passes=3",
+					"--param",
+					"max-inline-insns-single=1000",
+					"--param",
+					"max-inline-insns-auto=1000",
+					"--param",
+					"large-function-insns=6500",
+					"--param",
+					"inline-unit-growth=100",
+					"--param",
+					"max-inline-insns-recursive=1000",
+					"--param",
+					"max-inline-insns-recursive-auto=1000",
+					"--param",
+					"max-inline-recursive-depth=1000",
+					"--param",
+					"max-inline-recursive-depth-auto=1000",
+				);
 				PREBINDING = NO;
 				SDKROOT = /Developer/SDKs/MacOSX10.4u.sdk;
 			};

Most of these tweaks should apply to a G4 (I have an older AGP Sawtooth, a model that cannot use the dual-cpu upgrades, but I did put in a 1.5GHz upgrade that runs fine with most of the above tweaks, but it probably can't do PPC64 and the TUNING needs to be changed to G4 of course ).

I'm curious now, let's see how this build behaves.

Thanks for helping, and congrats for the "golden" release.