From alsa-devel-owner@alsa.jcu.cz  Mon Mar  8 20:15:43 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id UAA16650;
	Mon, 8 Mar 1999 20:15:28 +0100
Date: Mon, 8 Mar 1999 20:15:28 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: non-i386 architecture support?
In-Reply-To: <19990308200616.F391@ruhr-uni-bochum.de>
Message-ID: <Pine.LNX.3.96.990308200747.8020D-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Mon, 8 Mar 1999, Marcus Brinkmann wrote:

> 
> Hello,
> 
> one concerned user of a different architecture asked me if sufficient
> considerations have been made for support of non-i386 architectures in Alsa
> design.
> 
> Are non-i386 people working on Alsa? Should you ask non-i386 people to join
> and encourage them to revise the code for i386-ism's?

Yes, I'm able to test ALSA code on an alpha, too.

> I am not worried about driver stuff, as the kernel driver/library layer
> concept is rock solid, but what about endianess and bits (32/64)?

ALSA code is mostly 64-bit clean. I haven't machine with the big endian
byte order, but I don't think that there are major problems (maybe a few
routines in lowlevel drivers would need corrections).

We would have to be more strong for some structures which could be
stored and restored to a disk for example. I mean a instrument data for
a synthesizer to allow cross-platform copying of instruments.

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


