Forums

Full Version: the next big steps
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
The reason for using ints is because when you add up several short int samples you don't want overflows to cause the output to wrap around. You instead want to detect overflows and clamp the output to the max (or min) value. Also, working with the native word size of the machine should be faster.

The test function does load a sound buffer, skips forward a bit, and checks that the sample values read from the buffer match some hard coded values (lines 51 and 54 in sound.cpp) ... so I'm not sure how you can pass that test and fail to play reasonable audio, but you're right, a more comprehensive test is in order. I'll try to get to writing a more in-depth test this weekend.
abs1nth: I've got a new high level sound test function set up. Just run vdrift -test and look for a line like:

Code:
Sound callback testing: 512/512 = 100% PASS

This test just plays the test wave file (the first 512 samples) and looks for agreement with output from the callback on my computer. See data/test/testgoal.txt for the outputs from my computer. The outputs from your computer get dumped to data/test/testdump.txt

Does this help at all?
Sound callback testing: 512/512 = 100% PASS


weird...i can't imagine why this test passes and the sound output is garbage
Perhaps it's something about how the SDL library behaves on pc vs mac. I'm not sure how we could find that out, but the SDL_mixer library must have to deal with the same issues, so we could check that....


Also, try changing line 343 in sound.cpp

Code:
desired.samples = 1024;

to 4192, since that's what the "audio examples" code (which worked fine for you) used.
Hmm, the audio examples code is also using 8 bit audio, instead of 16 bit, which is where we'd run into endian issues....
as expected changing desired.samples makes no difference.
Bummer. I'm not sure what else I can do without being able to duplicate the bug myself. Could you try modifying the "audio examples" app to be 16-bit, and then perhaps load a wave file (you could use my existing WAV loading function).
abs1nth, update to R1698 and update your data to R4, and see if you still pass the test. I found out that the callback test wasn't actually exercising the pitch shifting sound sampler, which is what is used by all sounds currently in the game.
you are right now with the pitch testing the callback tests fail on ppc. however if i define RESAMPLE_QUALITY_MEDIUM instead of RESAMPLE_QUALITY_FAST_MEDIUM they succeed BUT sound output is still only garbage ;-((
Oops, I may have forgotten to put the bit swapping into the FAST_MEDIUM quality stuff... but I guess it doesn't matter in the short term anyway since your sound output is still garbage (dang).
abs1nth: try http://venzon.net/content/dev/vsound/vsoundtest.tar.bz2

see if you can play the included sound file, or if it's garbage
ok backported the fixes from revision 1701, defined RESAMPLE_QUALITY_MEDIUM instead of RESAMPLE_QUALITY_FAST_MEDIUM, all of the tests pass except the performance tests (slow machine) and one of the filter tests (fails also on intel, off by one, mentioned it some time ago) and the sound plays fine on little endian but is garbage on big endian.
ok revision 1703 finally makes the new sound engine work (partly) on big endian.
(i've tried the actual fix before but since there were so many layers of problems it didn't improve things. funny thing is that the callback testing actually SHOULD HAVE failed since it is testing shorts instead of chars and therefore has an endian problem itself)

could you commit a new testgoal.txt i've trouble committing to the new svn repository on sourceforge?

with the fixes in r1703 single files are played fine but there are still audible problems during a real race, guess some problem in the mixer (?) still persist. perhaps a new testcase for this could help...


btw. even on little endian there are some crackles when racing against opponents, is this expected?

joe, thanks for all your help regarding this issue! also the stripped down project which plays a single file really helped nail down the problem.
abs1nth, I think you should have commit access on the data SVN repository. use your SourceForge login/pass for access. Let me know if you still have trouble.
abs1nth: okay, stupid question here, but why don't we just byte-swap the entire sound file on load (or immediately after loading)? Wouldn't that remove the need to byte swap anywhere else?
Pages: 1 2 3 4 5