gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Fast conversion of unsigned audio samples to signed?[SOLVED]

#150612 - sowee - Fri Feb 08, 2008 3:14 pm

Hey there, does anybody know a fast way to convert unsigned to signed? I seem to be having problems with streaming 8-bit wavs from memory card because of the conversion..this is basically the method i use to fill the buffer that i stream

Code:
void FillRingBufferMono(void *stream, SoundStream *ssin, u32 numsamples)
{
   if( (ssin->data_pointer - 44) > ssin->length){ ssin->data_pointer = 44; fseek(ssin->fp, ssin->data_pointer, SEEK_SET);}
   if (ssin->data_pointer < 44) { ssin->data_pointer = 44;}   

   fread(stream, numsamples, (size_t)1, ssin->fp);            
   if (ssin->bits_per_sample == 8){
      toggleSignBit(stream, numsamples);                  
   }
   ssin->data_pointer+=numsamples;                     
}

and this is the method i use to convert to signed, which i got from darknight ez

Code:

void toggleSignBit(unsigned char *sample, unsigned int len) {
      for(; len > 0; --len, ++sample) {
         *sample ^= 0x80;
      }
}


It was running fine when i was doing some vram access in drawing to the framebuffer alongside the streaming maybe because the vram access delays the timing a bit so the conversion is able to make it.. but now i removed the drawing code and theres popping sounds for my steaming...so i think i need to optimize the code but don't really know how else to do it?

[Subject Fairy was here -- MOD]


Last edited by sowee on Sat Feb 16, 2008 3:16 pm; edited 1 time in total

#150617 - knight0fdragon - Fri Feb 08, 2008 5:45 pm

..um what haha

your topic could me misleading, you should change the topic from unsigned to signed sound files or something
anyway, it doesnt sound like an optimization issue with regards to the conversion, perhaps you are just not playing the sound properly, more code is going to have to be seen.

I have a feeling with the magic number 44 there, that you are not properly reading the wav file, since there are different variants to the wav header
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

#150624 - tepples - Fri Feb 08, 2008 9:41 pm

knight0fdragon is right: A robust RIFF WAVE (.wav) parser reads individual chunks, such as 'fmt ' and 'data'. The "44" comes from the "canonical wave format", a subset of RIFF WAVE that consists of a RIFF WAVE header followed immediately by the 'fmt ' chunk and the 'data' chunk.

I have written robust RIFF WAVE loading code. Want to see it?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#150641 - sowee - Sat Feb 09, 2008 3:32 am

oops sorry for the misleading title, regarding wave files, i know there are variations but the wav files i'm testing all follow the microsoft format..to my knowledge at least because i used sox on them, they were playing fine (without any pops or bugs, tested from mono 8 bit 11025, up to stereo 16 bit 48000) when i had a method that just drew to the framebuffer in the main loop, but for higher quality wave files, the top of my console screen flickers, so whatever text printed there blinks randomly.

When i removed the drawing method, the flickering stopped, but now the sound gets occassional pops, moreso for some sound formats (diff bit rates and frequency and channels), others seem to still work fine.. For stereo i don't use the method above, i have another which splits the interleaved data

#150644 - sowee - Sat Feb 09, 2008 6:48 am

i also want to ask... what effect does vram access have with regards to fifo or vblank?

when i have this my streamer runs perfectly fine:
Code:
void Texture2D_DrawSprite(Texture2D* sprite)
{
   VRAM_A[sprite->X + sprite->Y * SCREEN_WIDTH] = sprite->palette[sprite->pixels[0]];
   int i;
   for (i=0; i < sprite->width; i++)
   {
      VRAM_A[sprite->X + i + sprite->Y * SCREEN_WIDTH] = sprite->palette[sprite->pixels[i]];
      int j;
      for (j = 0; j < sprite->height; j++)
      {
         VRAM_A[sprite->X + i + (sprite->Y + j)* SCREEN_WIDTH ] = sprite->palette[sprite->pixels[i + (sprite->width * j)]];
      }
   }
}


i've tested and tested and this is the only piece of code which has a big effect on my streamer when i remove it and i really don't see the connection..[/code]

#150906 - josath - Thu Feb 14, 2008 6:11 pm

sowee wrote:
i used sox on them


If you're using sox anyway, why not just convert them to the correct format, and play them directly on the DS? instead of converting them to the wrong format, and trying to re-convert it on the DS...

#150909 - tepples - Thu Feb 14, 2008 10:22 pm

josath wrote:
sowee wrote:
i used sox on them

If you're using sox anyway, why not just convert them to the correct format, and play them directly on the DS? instead of converting them to the wrong format, and trying to re-convert it on the DS...

I would imagine that the users will be using converters other than SoX to add audio files, and the developer wants to make the program robust to those converters. Does, say, NitroTracker require the user to use SoX before importing samples?[1] GBA productions such as GSM Player could get away with requiring SoX because changing the appended file system required rebuilding and reflashing the NOR card. The DS, on the other hand, commonly uses FAT-formatted NAND cards, which allow files to be added or removed at will.

Besides, does SoX support writing out a custom container format without modifying the source code? If not, how does the DS program know the original wave's sample rate?[1]


[1] Answer to rhetorical question: It does not.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#150992 - sowee - Sat Feb 16, 2008 3:16 pm

ok it seems i was misunderstood, i'm not converting a format to another format on the ds nor do i want to know the original wave's sample format or anything to that effect, i just wanted to justify why i put the number 44 there by saying the wave files came from sox because those wave files are what i used for testing. anyway, the topic has strayed off i think..besides, i don't seem to have the problem anymore at the moment. Thanks.