Subject: Re: [linux-audio-dev] bytesex
From: David Olofson (audiality_AT_swipnet.se)
Date: to elo 26 1999 - 22:39:13 EDT
reactor/CTPmedia wrote:
> what should we do about bytesex? i want my program to run on every machine
> that has linux, not just on lousy 80x86s.
Code should work in the native format. Unless you do silly pointer
typecasting tricks, there's no need to worry about data formats except
when dealing with files and drivers. (That is, it's non-issue for signal
processing plug-ins.)
> a dude on irc said i should store my data in network format, using the
> system calls ntohl, ntohs, htonl, htons.
I'd say you should *store* data in the native format for preformance
reasons, but support reading of both formats to handle imported files.
The used endian format must of course, be indicated in the file headers!
OTOH, what I'm thinking about here is multitrack recording, where you
simply don't want to convert data on the fly for performance reasons -
the actual data chunks in files should be raw, and fit right into the
engine. It's not all that important when playing some single multimedia
file where the conversion takes .1% of your CPU time...
> i thought about that i should write (actually, rip out from Mikmod's source)
> specific filereading/writing routines for little and big endian machines.
Cool for data file portability, but rather pointless for writing
temporary/internal files from multimedia engines. Anyway, endian format
is defined in all (usable) standard file formats, so you kind of can't
miss it when writing read/write code for the. If you ever tried to code
a MOD file reader for x86, you should know what I mean... :-)
//David
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST