Re: multitasking

On 2017-10-25 01:29, Glenn English wrote:
> On Tue, Oct 24, 2017 at 7:44 PM, Jeremy Nicoll - ml sox users
> <[email protected]> wrote:
> 
>> I can't answer the question, but I think whoever does will need to 
>> know
>> more.  Are these multiple capabilities needed on different pieces of
>> audio, but all being processed at the same time?
> 
> No, just one hugish (1G++) flac file, processed in several different 
> ways.
> 
>> Or do you mean that for one audio source a whole sequence of things
>> are to be done to it?
> 
> Got it :-)
> 
>>  - which seems to me to be one sox command with various effects
>>    coded one afetr another
> 
> That's another possibility, but it takes a very long time to cat a
> billion little flacs into a single or mp3 it, so I assumed it'd take a
> long time to eq or compress the huge flac, so I wanted to do several
> things in parallel. That's not a deal killer because this program is
> being designed to do the SoX part(s) of the job with no human
> intervention. But I'd like to get its job done overnight.

It's either one huge file, or it's not.

I have no idea whether for the effects you wish to use it'd make any
difference whether you apply them to all the small files first, then
concatenate the results, or whether some/all will only work properly
if applied to the huge file.

On Windows, if a script issues

   start sox ...

(though such a command tends to look rather more like

  start /b "atitle" "c:\x\y\z\sox.exe" arg1 arg2 arg3...  )

then that started sox runs in a different process from the one that
the script is running under, and therefore a script could issue a
series of "start sox..." commands at a time.  However if, say, it
issued 7 of these (if one had a 4 cpu ie 8 core machine) there'd be
no easy way to find out when each sox command stopped so it was a
good time to start another one.

On the other hand if you divided your umpteen files into, say, 7
lists of files you could have your master script start 7 subsidiary
scripts with "start .. whatever's needed to start that script" and
then each one could issue a sox command, then when that's complete
issue the next one and so on.  You might find that 7 sets of sox
commands was too many on an 8 core machine; it depends what else
has to run at the same time.

If I were doing that I would have the subsidiary script create when
it starts a flag file unique to it, then check that file exists each
time it's about to issue another sox command.  If not, stop.  That
way you can easily stop one set of commands by deleting its flag file.
Scripts I have that do that also delete the unique flagfile when they
stop naturally.



-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot