+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: the next big steps (/showthread.php?tid=562)
- joevenzon - 04-12-2007
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.
- joevenzon - 04-14-2007
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% PASSThis 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?
- abs1nth - 04-14-2007
Sound callback testing: 512/512 = 100% PASS
weird...i can't imagine why this test passes and the sound output is garbage
- joevenzon - 04-15-2007
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.
- joevenzon - 04-15-2007
Hmm, the audio examples code is also using 8 bit audio, instead of 16 bit, which is where we'd run into endian issues....
- abs1nth - 04-16-2007
as expected changing desired.samples makes no difference.
- joevenzon - 04-16-2007
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).
- joevenzon - 04-26-2007
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.
- abs1nth - 04-27-2007
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 ;-((
- joevenzon - 04-27-2007
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).
- joevenzon - 04-28-2007
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
- abs1nth - 04-28-2007
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.
- abs1nth - 04-28-2007
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.
- thelusiv - 04-29-2007
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.
- joevenzon - 05-06-2007
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?