[Live-devel] streaming WAV files...

Ross Finlayson finlayson at live.com
Mon Apr 12 03:07:07 PDT 2004

>1) Just a little confused by your explanation (I'm new to 
>networking...).  From your explanation, I gather network order is 
>big-endian.  You state that this conversion for a WAV file was *incorrect* 
>to do "...before streaming them".  Yet your last line on what the 
>*correct* procedure to do also says "... convert ... from little to 
>big-endian order prior to streaming."  Curious why there would be any 
>endian conversion at all, seeing as that should be the client's 
>responsibility before placing it in some audio buffer, no?


Here's another explanation:
- When 16-bit PCM audio samples are streamed over the network (using RTP), 
they *must* be sent in big-endian order (see RFC 3551, section 4.5.11).
- However, within WAV audio files, the 16-bit PCM audio samples are stored 
in little-endian order.
Therefore, when streaming from WAV audio files (using RTP), the 16-bit PCM 
audio samples read from the file must always be byte-swapped before being 
sent via RTP.  (The mistake I was making before was doing the byte swapping 
only on little-endian computers - which was wrong.)

But, in any case, the bottom line is that WAV audio streaming should now 
work for you (even on a Mac).

>2) In setting up my development environment, I had to change all *.hh 
>files to *.h (since my IDE -- XCode -- doesn't let users define extension 

I'm surprised by this.  Noone else has ever reported any problems with 
building the code on MacOS (after doing "genMakefiles macos").  Are you 
sure that this is something that you *have* to do?

BTW, the reason for using ".hh" is to help distinguish C++ header files 
from C header files (for people who are browsing the code).

If the use of ".hh" file names turns out to be a major hassle, then I 
suppose I could change this (rename them all to "*.h"), but this is the 
first time I've heard of the ".hh" names causing a problem.

More information about the live-devel mailing list