ogg dev - Jan 2008 - OggPCM: support for little-endianness only?

List,

A recent discussion over on XiphWiki is trying to decide if OggPCM
should support only little-endianness or the usual combo of big and
little.

It started with the following statement by an user (Qqq):

"Portable players are usually ARM, which is usually little-endian. The
Macintosh is now little-endian. Obviously the PC is little-endian.
Clearly there is a winner. It's long past time to stop putting the
bytes in an order that makes both programmers and computers do extra
work for no good reason. Don't try to hold back the tide."

Thoughts?

It's being hard to reach a consensus considering the little amount of
people interested in OggPCM while also actively looking into the
latest developments in the wiki, and since there are more eyes here I
rather move the dicussion to the list.

-Ivo

P.S: Actually I never understood if OggPCM topics should go on ogg-dev
or vorbis-dev.

Ivo Emanuel Gon?alves wrote:
> List,
> 
> A recent discussion over on XiphWiki is trying to decide if OggPCM
> should support only little-endianness or the usual combo of big and
> little.
> 
> It started with the following statement by an user (Qqq):
> 
> "Portable players are usually ARM, which is usually little-endian. The
> Macintosh is now little-endian. Obviously the PC is little-endian.
> Clearly there is a winner. It's long past time to stop putting the
> bytes in an order that makes both programmers and computers do extra
> work for no good reason. Don't try to hold back the tide."
> 
> Thoughts?
> 
Really it's pretty trivial and hardly taxing on the processor either.
As far as I can tell the OggPCM standard was designed to provide a
way to wrap and describe arbitrary PCM data[1].  If you prefer to
distribute it in little endian all well and good.

Actually, if you wanted to come up with an argument for either it
would be that big endian lets you strip bytes off the end of a
sample arbitrarily.

[1] Those who actually developed it may disagree.

-- 
imalone

Ian Malone wrote:
 > Ivo Emanuel Gon?alves wrote:
 >> List,
 >>
 >> A recent discussion over on XiphWiki is trying to decide if OggPCM
 >> should support only little-endianness or the usual combo of big and
 >> little.
 >>
 >> It started with the following statement by an user (Qqq):
 >>
 >> "Portable players are usually ARM, which is usually
little-endian. The
 >> Macintosh is now little-endian. Obviously the PC is little-endian.
 >> Clearly there is a winner. It's long past time to stop putting the
 >> bytes in an order that makes both programmers and computers do extra
 >> work for no good reason. Don't try to hold back the tide."
 >>
 >> Thoughts?
 >>
 >
 > Really it's pretty trivial and hardly taxing on the processor either.
 > As far as I can tell the OggPCM standard was designed to provide a
 > way to wrap and describe arbitrary PCM data[1].  If you prefer to
 > distribute it in little endian all well and good.
 >

Addendum: no matter what choice is made you will end up doing type
conversion anyway, says Mr Murphy.

-- 
imalone

On 2007-12-30, Ian Malone wrote:
> Really it's pretty trivial and hardly taxing on the processor either. 
> As far as I can tell the OggPCM standard was designed to provide a way 
> to wrap and describe arbitrary PCM data[1].  If you prefer to 
> distribute it in little endian all well and good.
My thoughts exactly.

On a related note, comments on the reworked channel mapping headers 
would be appreciated. I think they're finally in workable shape.
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Ivo Emanuel Gon?alves wrote:
> Clearly there is a winner. It's long past time to stop putting the
> bytes in an order that makes both programmers and computers do extra
> work for no good reason. Don't try to hold back the tide."
It doesn't even really matter which architecture you're actually on. In
any format that is to be used on both, it is always better to pick one
and stick with it. Otherwise you require _both_ architectures to write
additional code that is largely useless. Unless you can guarantee that
you're writing streams that are only going to be passed within a single
architecture, allowing both formats is always worse. That happens seldom
enough in practice and has a small enough benefit that it is in no way
worth making everyone else do extra work.

Timothy B. Terriberry wrote:
> It doesn't even really matter which architecture you're actually
on. In
> any format that is to be used on both, it is always better to pick one
> and stick with it. Otherwise you require _both_ architectures to write
> additional code that is largely useless. Unless you can guarantee that
> you're writing streams that are only going to be passed within a single
> architecture, allowing both formats is always worse. That happens seldom
> enough in practice and has a small enough benefit that it is in no way
> worth making everyone else do extra work.
For a compressed format I would agree 100%, but PCM is not a compressed
format; its a format that if the endian-nesses of the file and CPU match,
can be dumped from file to disk and disk to file without any processing.

In libsndfile I handle this by doing a straight read or write when the
endian-nesses match and endswapping where I have to. For a data format 
as simple as PCM the minor effort required for a couple of different code 
paths is well worth it for the performance payoff.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"We can build a better product than Linux" -- Microsoft
Corp.'s Windows operating-system chief, Jim Allchin.
One has to wonder why, with their huge resources, they haven't.
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"So if you were to say 'Microsoft,' I'd say 'Where? Let me
grab
me my stake and crucifix!'." -- Bridget Kulakauskas

On 2007-12-30, Timothy B. Terriberry wrote:
> In any format that is to be used on both, it is always better to pick 
> one and stick with it.
Then recommend one single format. Nobody *has* to support all of the 
features present, yet it makes sense to *allow* common variances. Most 
of all, because:
> Unless you can guarantee that you're writing streams that are only 
> going to be passed within a single architecture, allowing both formats 
> is always worse.
...some people *are* able to guarantee that. Why hinder them?
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2