[vorbis-dev] Parallelism

[Adam Scriven]

At 17:53 2000/08/18 -0400, you wrote:
>On Fri, 18 Aug 2000, Timothy Wayper wrote:
> > Well, what it I want to compress my original Tubular Bells CD, which I
> > happen to be listening to at the moment, that only has two continuous
> > tracks, each 20 minutes long? What if I only want to compress one of these
> > tracks but I have 4 CPU's in my machine? I really don't think your idea of
> > "sensible workloads" is valid, unless all the music you listen too is in
>[snip]
>
>I don't understand why you would need multiple cpus doing encoding if all 
>you are encoding is a single track or single CD.  It's just silly, and a 
>waste of time. People who are already doing bulk encoding (encoded over 
>1000 CDs into mp3, about to begin again redoing it all w/ vorbis) are 
>perfectly happy with the one track or one disk to cpu method.

Are we?  I have 300+ CD's to encode, and anything that can make it faster, 
without the loss of quality, the better.

If I could harness the power of the other machines on my network, it would 
speed up the process that little bit, and overall would be faster.
That's why things like Seti at Home work, as well.
The more CPUs, the faster.  Why would you limit any software, especially 
math intensive software, when there's no need too.
IF the code doesn't slow down single-CPU encoding, then what's the problem?

>The human loading the disks into the drives and checking the CDDB results 
>(and doing
>complete entry in the frequent case where the CDDB data is missing or very 
>inaccurate) is the limiting factor and all the CPUs and MPI parallel
>encoders in the world can't help.

IF they do that.  As was mentioned before, you could just set it to GO, 
ignore the CDDB entries, and fix them later if they need it, after the fact.
IF you don't check the CDDB entries, they take seconds.  The ripping takes 
very little time, but the encoding is the CPU intensive part, and takes the 
most time.

>If you have code to do it with minimal impact to the source base, then 
>great. Until then the discussion should stop.

And that's how Jeff Started this conversation, asking questions about the 
project, and offering to code it for parallism.
And why should the discussion stop? This is a Development Discussion list, 
and we're talking about one thread of the discussion.

I think the criteria for adding things like this should be:
1) It must not slow down the default action (in this case, single CPU, 
single process).
2) It should be command-line switchable.  If you like encoding that way, 
Gregory, then you can just "ogglame song.wav song.ogg" as you normally 
do.  But for those who have the parallel computing environment setup 
already, we can "ogglame --parallel song.wav song.ogg", and be faster.
3) Most Importantly! The audio quality MUST NOT SUFFER.

If it can be coded to meet the above 3 criteria, go for it!

Simple, elegant, and as was said before, potential PR too.  I've only seen 
ONE distributed MP3 encoder, and that functioned like a distributed.net 
client for Windows, running from an NT server.

If vorbis has the functionality built in, that's a Good Thing(tm). Let the 
discussion continue! 8-)

My $0.02.
Adam
Toronto, Ontario, Canada

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/