GP2X Scratchy Sound (sdl And /dev/mixer)

[Micket]

Hi i recently added support for GameCube music which uses the in_cube plugin for xmms.
But im getting horrible sound quality. Scratchy sound, high frequent ticks, just a noise that almost drowns the music in alot of songs.

I snagged off the stream of shorts that the plugins are asked to fill by oldplay (OldPlay simply provides a buffer and a length and lets the plugins fill it up) to a file and rendered a wave from it in matlab and it sounds perfect.
I've also compared the values in the stream to that of other plugins and can't see anything out of the ordinary. Roughly the same amplitude, both negative and positive values.. well. not much else to see in a short*

So i tried forcing down the sample rate. Same thing just slower.

I am no expert on how OldPlay handles the stream after that. What i'd like to do is check to see exactly what values that are beeing sent to /dev/mixer

I'm at a loss here. I see nothing wrong, and the sound is good enough that you can actually hear the melody and all.


Some relevant files are
http://www.micket.com/oldplay/src/MusicPlayer.cpp
http://www.micket.com/oldplay/src/Fifo.cpp

(not USE_DEV_MIXER is defined)

 

[BradN]

I don't think /dev/mixer accepts audio samples, it's only for volume changes (like a mixer board). Probably you mean /dev/dsp

 

[Micket]

Ah yes. I only took a quick look and noticed /dev/mixer in the code
Can i perhaps set up SDL to print out the samples to a file instead of /dev/dsp?

 

[BradN]

You could probably alter it to send the samples to stdout, and then run the program over usb networking and capture the output on a computer. I see you've already found the alignment thread (that would have been my first guess as to what the problem might be).

 

[Micket]

Aligntment? Wouldn't that trash the samples completely? I mean it's still good enough to hear the melody quite clearly.
Either way it's an interesting thought i will recompile in_cube with warning on alignment increasing casts

 

[BradN]

Hmm, if that doesn't help, another thought is that maybe only some of the channels getting mixed together are messed up? If there's mixing code specific to that format, you could dump (or checksum) the individual channels and see how they're doing, and narrow down whether it's the mixing causing problems or if it was scrambled earlier.

At least this should be one of the easier things to troubleshoot, because you have a working system with the same code, and you can compare the data flow at arbitrary points and see where things go wrong.

 

[Micket]

EDIT:
Actually i found the problem now. Another one of the many surprises the lack of comments and documentation has given me in OldPlay
Appearantly the function that fills the buffer asks for a certain amount of bytes, not samples, (which i find quite stupid to start with)
to be filled and well.
I was writing twice the amount (the buffer it uses was actually declared to fit that amount in samples, thus making if halfempty all the time as far as i can see)
and the later half never got used by SDL.
Anyway thanks for the help! I'm off to release another oldplay version now


Old message:
Ok, i have been printing out the samples (in the callback function)
I figured the samples should be arranged as every other channel, so i printed out samples with;

	FILE *fp = fopen("audio_cb_out","ab");
	for(int i=0;i<len;i+=2) 
	{
		fwrite(dest+i,sizeof(short),1,fp);
	}
	fclose(fp);

and then played this back after loading the shorts as little endian in octave and using playaudio()

The surprising thing is that this sounds good ONLY for GameCube music, and everything else sounds really really bad (you can just barely hear the melody)

I've also just used printf and compared to the values i get after reading the produced file in octave and they match, so nothinng should be wrong in that process.

So basicly, what should i be feeding the buffer in the callback function in order to get a correct sound?
If i have signed shorts, on every other channel it should sound correct right?