protux-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Protux-devel] mustux and protux automake updated


From: Martin Herren
Subject: Re: [Protux-devel] mustux and protux automake updated
Date: Mon, 28 Oct 2002 17:30:27 +0100

Luciano Giordana wrote:
> 
> On Tuesday 15 October 2002 11:34 am, Martin Herren wrote:
> > btw: as soon as i got some time, i'll try to find a fix for file
> > compatibility between my PC and my Sparc, something like detection of byte
> > endianess before the file is loaded, and on-the-fly conversion of the file
> > before loading if required... this will slow down the first loading of a
> > file coming from a computer having a different endianess due to the
> > conversion, but won't affect any other part of the code.
> 
> the best way I can imagine is to put some compilation directives.

i don't think that it is necessary to have compilation directives for
that, as ProTux doesn't even need to be aware of its own endianess, as
long as it can detect 'other' files and convert them before loading.
Forcing the fileformat to little-endian would imply a performance loss
for all big-endian computer, and i don't think that this is great in the
case of a multi-track audio recording software ;-) So i think it is
necessary that all platforms work native-endian, and also write
native-endian files. The magic number could be set as FARP instead of
PRAF to identify the file.

The only problem i see for the moment with my solution is that a user
doesn't expect the file to change if he only loads and plays it, so the
file should be converted into a temporary file, and the user should be
asked if he wants to convert the original file. Otherwise the tmp-file
is used for playing.

> I also pan to replace all "short" references to a compiler definition "SAMPLE"
> 
> so it can be edited on a single place to determine the way it is compiled

yeah, the size of datatypes is also a problem. Ultra-Sparc Linux uses
usually the same as intel (as userland is usually running 32-bit), so
for me it's not a problem yet... but the sooner we fix it, the easier it
will be...
A clean solution would be to uses glib's datatypes which guarantees a
specific size...

I'll be away for 3 weeks, when i come back i'll try to take a closer
look at the file-endianess issues...

/Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]