Re: [AD] Speed wav loader way up

[Peter Wang <novalazy@xxxxxxxxxx>]

On 14 April 2010 13:10, Trent Gamblin <trent@xxxxxxxxxx> wrote:
> On Tue, April 13, 2010 7:12 pm, Peter Wang said:
>> That looks right.  The overhead is from the individual al_fgetc calls,
>> which have to go through the file stream vtable.
>>
>> The optimisation would be to read a whole buffer of 16-bit sample values into
>> the buffer with a single al_fread call.  Then for #ifdef ALLEGRO_BIGENDIAN, make
>> a pass over the buffer to swap the endianness.  PCM data in wave files is little
>> endian, unless the identifier is "RIFX", which we apparently don't support.[1]
>
> How's this?

> Index: wav.c
> ===================================================================
> --- wav.c	(revision 13232)
> +++ wav.c	(working copy)
> @@ -182,21 +182,23 @@
>     n = wavfile->channels * samples;
>
>     if (wavfile->bits == 8) {
> -      return al_fread(wavfile->f, data, n) / wavfile->channels;
> +      return al_fread(wavfile->f, data, n*2) / (wavfile->channels*2);

That looks wrong.

>     }
>     else {
> -      size_t i;
> -      signed short *d = (signed short *) data;
> +      long bytes = al_fread(wavfile->f, data, n*2) / (wavfile->channels*2);

'bytes' is the wrong word. I suggest:

    size_t bytes = al_fread(wavfile->f, data, n * sizeof(int16_t));
    n = bytes / sizeof(int16_t);

>
> -      for (i = 0; i < n; i++) {
> -         signed short s;
> -         if (!read16(wavfile->f, &s))
> -            break;

/* PCM data in RIFF WAV files is little endian.
 * PCM data in RIFX WAV files is big endian (which we don't support).
 */

> +#ifdef ALLEGRO_BIGENDIAN
> +      int i;
> +      unsigned char tmp, *p = data;
>
> -         *d++ = s;
> +      for (i = 0; i < n*2; i += 2) {
> +         tmp = data[i];
> +         data[i] = data[i+1];
> +         data[i+1] = tmp;
>        }
> +#endif

>
> -      return i / wavfile->channels;
> +      return bytes;

return n;

>     }
>  }

Are you able to test it on a big endian processor?

Peter