On Tue, Sep 17, 2002 at 09:56:30AM +1000, Toby Sargeant wrote: > On Mon, Sep 16, 2002 at 08:21:28PM +0200, Michel D?nzer wrote: > > > > That's correct. The problem is probably a mismatch between what xmms (or > > its plugins) _thinks_ the endianness of the PCM data they send to the > > device is (and thus tells the device) and what it _actually_ is. E.g., > > this works with dmasound if the app thinks its data is little endian but > > it's native endian in fact (a common mistake), because dmasound never > > swaps bytes. In contrast, ALSA will swap bytes, and you'll hear noise; > > an effort in vain. > > > > There is some support for little endian formats in dmasound_pmac. I > don't believe the software resampling will ever change endianness, but > on older macs, hardware byteswapping of samples exists, and > dmasound_pmac will use it (well, the code's there, but I don't have an > older mac to see whether it's actually getting called ;)). > > Basically, on i2c based macs (Tumbler, Snapper, DACA) the only format > supported natively is 16 bit signed big endian. On older macs (AWACS, > Snapper, Burgundy), big and little endian formats are supported. > > Then sample conversion is done in software if the format doesn't match. > This doesn't include byte swapping, which means that stuff like audacity > is left out in the cold. > > It's possible that alsa assumes that you can do byteswapping on all > macs, and so any apps that use little endian sample formats instead of > just sticking with platform native will have probs.
<dumbquestion> Why don't they just put a header on the sample that indicates its endianness? IIRC that's how tiff works. </dumbquestion> -- *------v--------- Installing Debian GNU/Linux 3.0 --------v------* | <http://www.debian.org/releases/stable/installmanual> | | debian-imac: <http://debian-imac.sourceforge.net> | | Chris Tillman [EMAIL PROTECTED] | | To Have, Give All to All (ACIM) | *----------------------------------------------------------------*
