ogg dev - Nov 2005 - OggPCM : Need more justification for chunked data

HI all,

John Kkoleszar has asked for the option of storing data. He gave the rational
that 

   a) SIMD optimized filters
   b) Writing filter chains.

Conrad Parker supported this say that both Core Audio and Jack operate on
multiple single channel buffers.

On IRC both Jean-Marc and MikeS argued that if OggPCM supports interleaved,
the addition of chunked is hard to justify.

My slant on the matter is that its harder to justify having both chunked 
and interleaved than it is to justify having one or the other.

So, we're looing for more feedback on this issue? Do we support chunked,
interleaved or both?

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"I want to make sure (a user) can't get through ... an online
experience without hitting a Microsoft ad."
 - Microsoft CEO, Steve Ballmer on the Microsoft search engine.

Hi all,

Conrad, MikeS, Silvia, Erik, Illi, John and I have been working on
another spec. It's definitely not final, but it should address several
issues with the previous one. Please comment:
http://wiki.xiph.org/index.php/OggPCM2

Two other issues that remained were:
1) Need for minor version (Silvia and I want it, MikeS is against)
2) Having the header 32-bit aligned vs. making the channel field 8 bits

	Jean-Marc

Le lundi 14 novembre 2005 ? 23:03 +1100, Erik de Castro Lopo a ?crit
:
> HI all,
> 
> John Kkoleszar has asked for the option of storing data. He gave the
rational
> that 
> 
>    a) SIMD optimized filters
>    b) Writing filter chains.
> 
> Conrad Parker supported this say that both Core Audio and Jack operate on
> multiple single channel buffers.
> 
> On IRC both Jean-Marc and MikeS argued that if OggPCM supports interleaved,
> the addition of chunked is hard to justify.
> 
> My slant on the matter is that its harder to justify having both chunked 
> and interleaved than it is to justify having one or the other.
> 
> So, we're looing for more feedback on this issue? Do we support
chunked,
> interleaved or both?
> 
> Cheers,
> Erik

Jean-Marc Valin wrote:
> Two other issues that remained were:
> 1) Need for minor version (Silvia and I want it, MikeS is against)
> 2) Having the header 32-bit aligned vs. making the channel field 8 bits
Alternatively, make it 16-bit (or 8-bit and define the next byte as 
"padding") and shrink the "significant bits" field to 16 as
well. Having
2^32 significant bits seems rather unuseful?

I do see that the channel info encoding is in here. Not different 
formats/width per channel. Does that need discussion?

Rene.