Multithreading, process priority..

[Amol]

thread synchronization

if all process have default value 1 in multithreading synchronization then which thread execute 1

[Spoon-]

Re: Multithreading, process priority..

>(2) Soon, i'll be upgrading to an Athlon64 X2. I'm thinking it'd be sweet if dB could
> run two or more LAME threads simultaneously.

Multi-threaded encoding is being written, about 15% done. It is not as simple as running to CLI encoders, especially when ripping from a CD, but I have a system that should work well (as long as you have 512MB or above).

[gmarsh]

Re: Multithreading, process priority..

expiry makes it go away?

hmm. Guess it's time to stop being a cheap bastard and register the thing

Thanks!

[LtData]

Re: Multithreading, process priority..

If your PowerPack trial has expired, you won't have a choice for adjusting the priority of dMC.

[xoas]

Re: Multithreading, process priority..

I'm using plain dB file selector which calls dB music converter, and I don't see a priority selection anywhere.

If you are accessing dMC through file selector, wait for your batch conversion to start taking place. There are 2 windows that will open to show the progress of the conversion (assuming this is a batch conversion). One shows the progress for the whole batch. The other displays the conversion rate for each file as it is getting converted. It is this window where, if you have Power Pack, you can set the conversion priority for your ripping and setting it to "Below Average" is what I use and recommend. Once set, your conversion priority should remain unchanged until you adjust it again.

Best wishes,
Bill

[gmarsh]

Re: Multithreading, process priority..

I'm using the "MP3 (lame.exe)" compressor. I'm using plain dB file selector which calls dB music converter, and I don't see a priority selection anywhere.

And by multithreading, I mean running two or more instances of the lame.exe (or whatever) compressor simultaneously. This will cause more I/O stress on the machine and won't offer much of an improvement if the decode/encode process is I/O limited by a lack of ram, slow drives, etc... but if the encode process itself (eg, flac -> lame --aps) is very CPU intensive and/or you've got reasonably fast disks and RAM to buffer everything then it can offer a huge improvement.

This is common practice - eg. running "make -j2 bzImage" when you compile a linux kernel will launch two simultaneous gcc threads, greatly speeding up linux kernel compilation on multiprocessor computers.

[LtData]

Re: Multithreading, process priority..

Unfortunately, encoding stresses the entire machine, not just the CPU. To get a performance benefit from encoding, you'll need to get the codecs themselves to become multi-threaded.

[xoas]

Re: Multithreading, process priority..

...external LAME compressor...

Is this using the generic CLI codec or what? Can you be a bit more specific?
If you have Power Pack (and this may be the source of your problem) you can set ripping priiority for dMC through a menu on the window that shows the progress of your conversion. If you set ripping priority in this manner, ripping priority for dMC should remain fixed once you set it until or unless you reset it. This is true for a whole batch, it will stay fixed between batches and it should stay fixed regardless of interface (eg, whether you access through Audio CD Input, File Selector, dMC or even CD Writer) for multiple runs, even days apart with system shutdowns in between sessions.

As for #2, are you talking abouot ripping/cpnverting different files simoultaneously on a 2 processor machine?

Best wishes,
Bill

[gmarsh]

Here's my wishes:

(1) Right now, running dBpowerAMP on my AthlonXP with an external LAME compressor more or less renders my computer unusable - eg, it takes a second for a window to come up when I click on the Windows XP taskbar. If I bring up task manager and lower the priority for the LAME task to "below normal", windows behaves much more 'nicely' and the encoding speed isn't affected much at all - that is, until that LAME process finishes and dB starts encoding the next file.

How about adding a process priority adjustment, so the user can select "below normal", "idle", etc... by default?

(2) Soon, i'll be upgrading to an Athlon64 X2. I'm thinking it'd be sweet if dB could run two or more LAME threads simultaneously. :D

Thanks!