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. Toby.