[Live-devel] streaming WAV files...

[Ross Finlayson]

>i'm adapting the WAV code you've written, and looking at the get*Bytes, it 
>looks like you're swapping the order; i.e., reading the file which is in 
>little-endian, but swapping the return val to be in big-endian.

No.  The "get4Bytes()" and "get2Bytes()" functions (in 
"WAVAudioFileSource.cpp") read bytes from the file - assuming that these 
bytes are stored in the file in little-endian order - and then return the 
result in *host byte order* - i.e., the native byte order of the local 
computer.

E.g, suppose that the two bytes forming the "numChannels" field are stored 
in the file, in order, as 0x02 and 0x00.  Then, when this data is read by 
"get2Bytes()", then the actual returned value - as a 2-byte 'short' - will 
be 0x0002.  This is true on both little-endian and big-endian computers.

But note that this is done only for the *headers* in the WAV file - i.e. 
fields like audio format, sampling frequency, length, and number of 
channels.  The actual audio sample bytes - which occur after the WAV header 
- are read sequentially, in little-endian order, and are not byte-swapped 
until just before they are actually packed into outgoing RTP 
packets.  (This is because the RTP payload format requires that the sample 
data in RTP packets be big-endian.)

>i'm curious why you took this approach of bothering to swap (assuming my 
>reading of the code is correct...).  It's great for me, since i'm running 
>on a mac and I need values in big-endian, but a port to intel chips while 
>implementing stricter error-checking would need a re-swapping...

No, the WAV *header* values read by "WAVAudioFileSource" will be correct on 
any architecture, and you will not need to change them.  However, the PCM 
audio *sample* data will need to be byte-swapped, if you want to play it on 
a big-endian machine (or if you want to stream it using RTP, as the current 
code does now).


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>