The answer here lies inside DataSocket, but I don't think it's a bug.
Here's what I think is happening:
1. LabVIEW is asked to retrieve the resource in this example (tone.wav) via DataSocket
2. LV/DS recognizes that it's not interacting with a DS server on the other end, but instead an FTP server
3. LV/DS recognizes that it's being asked to retrieve a special file type--a WAV file
Both 2) and 3) impact the end result. If the example were asking a remote DS server (versus an FTP server) for a specific piece of info that was being published by the server, the info would be served up exactly as it was published on the server side--all information preserved.
However, when the DS Read VI isn't talking to a DS server, there has to be extra code down in there th
at handles special cases like WAV files. In the case of WAV, I imagine that the function strips any header info out of the WAV file and returns only the waveform component to LabVIEW as an array, because the waveform is really the part that you want to graph or analyze in LabVIEW.
As an aside, the example also uses a DBL array instead of a U8 array, probably because it's intended to handle everything listed plus other things a user might try (like a 16-bit WAV). I think tone.wav is an 8-bit source, and as a result, the array you save to disk and try to play in a media player is completely different (and 8 times bigger) than the original WAV file.
I suppose the thing to keep in mind is that DataSocket really isn't equivalent to FTP; the way it handles data sourced from non-DS servers is optimized for proper presentation in the software environment being used.
Hope it helps,
John Lum
National Instruments
