Endianness reversing is implemented too many times in 3.9a7029.
It is like a collection of successive independant coding accumulated.

We must reverse bytes in wordArray at startup if we transfer image on another 
machine, or for binary I/O.
There are only four cases:
 we have long 1234, we want 4321
  at startup, the VM does that for us... nothing to do
  for Binary I/O, Bitmap class>>swapBytesIn:from:to: does swap long (32 bits) 
 we have short 12,34 we want 21,43
  at startup, VM does scramble 4321, we have two implementations:
      ArrayedCollection>>swapHalves and ShortIntegerObject>>swapShortObjects
  for binary I/O, this is re-implemented a lot of times!

My proposition is to have three generic BitBlt tricks
 Bitmap class>>swapLongIn:from:to:
 Bitmap class>>swapShortIn:from:to:
 Bitmap class>>swapHalvesIn:from:to:
Maybe a  swapLongLong would be usefull too...

Then to define reverseEndianness everywhere, with default:
 pointers | bytes => do nothing
 word => Bitmap swapLongIn: self from: 1 to: self basicSize

Redefined reverseEndianness  in ShortIntegerArray SoundBuffer & co
 Bitmap swapShortIn: self from: 1 to: self basicSize

Then to define restoreEndianness generic:
     SmalltalkImage current isLittleEndian ifTrue: [self reverseEndianness]

Then to call uniformely swapHalves at startup for short things...

I can proceed with theses changes, but cannot test bigEndian...
Any objection to these changes ?
Note that this should speed up ShortIntegerArray streaming on x86...

Note that a service like swapShortAt: swapLongAt: swapLongLongAt: is missing 
in ByteArray, though usefull to store/retrieve information in native format 
(especially for FFI). And BitBlt trick should not work for ByteArray... Or 
should it ?

Nicolas