[Live-devel] streaming WAV files...

[Ross Finlayson]

>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?

Matt,

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 
>mappings).

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.