Posts Tagged ‘AudioX’

If you have not been by the site recently, I have updated a few my applications this week, and I have added a pair of new apps as well.

The newcomers include AudioX and RAIDFix.

AudioX is a labor of love several years in the works. A process born in batch files, migrated to Perl, and eventually rewritten in C#, AudioX converts songs between audio formats including FLAC, APE, AAC, MP3, and WAV. I really needed an application to convert my APE audio to FLAC for archival, and to compress my FLAC audio to AAC format for my iPod and MP3 format for my car. AudioX does this for me, managing tags and album art, all while taking advantage of PCs with multiple cores. It’s a great app, give it a try!

RAIDFix is an application I wrote to help the countless people that visit my site looking for a way to enable RAID on their Intel ICH-based Windows PC after they have installed Windows with RAID disabled. I have published walkthroughs on how to accomplish this, but RAIDFix makes it extremely simple. Patching your computer to allow you to enable RAID in the BIOS is now one-click away.

Additionally, Suction received updates to allow the user to specify the text they want used when renaming duplicate files as well as the ability to specify whether this text is prepended or appended to the file name.

MailBin had a bit of work done on the back-end, in order to do away with the flat configuration file used by the program. Instead, MailBin now uses Windows’ standard user config files like the rest of my applications.

All of the applications listed above now take advantage of my new web-based update system. The programs will check this web site to see if there is an update version of the application automatically, alerting you if a new release has been published.

Is there such a thing as too many threads?  Of course there is.  Well, for the time being, that is.

I am currently putting together an audio conversion application, and I was doing some testing to see what number of concurrent conversions produced the best results in respect to time.  Conventional wisdom says that “bigger/more is better”, but not necessarily in this case.

During my testing, I converted a series of 15 songs from FLAC format to AAC format, all on the same PC armed with a 3.0 GHz Quad Core processor and 4 GB of memory.  The drive on which the data was stored and written to is a Seagate Barracuda SATA drive.  I simply ran the conversion using one thread and incremented the thread count after each iteration until I had 8 concurrent threads running.

The results are as follows:

1 Thread – 125 Seconds
2 Threads – 64 Seconds (-61s)
3 Threads – 45 Seconds (-19s)
4 Threads – 36 Seconds (-9s)
5 Threads – 37 Seconds (+1s)
6 Threads – 35 Seconds (-2s)
7 Threads – 35 Seconds (-0s)
8 Threads – 35 Seconds (-0s)

As you can see, performance pretty much plateaus around the 4 Thread mark and barely increases after that.

It makes sense that a 4-core machine gets good performance when 4 separate threads are running.  The processor was not being utilized 100% however, which is why I decided to try increasing the concurrent thread count.

I would assume that the extra overhead involved with managing additional threads, along with the cost of constant context-switching at the core-level outweighs the benefits of having additional processes running at the same time.  Initially, I thought that the hard drive might be the limiting factor here, but when running the same conversion from two SATA drives in RAID 0 configuration, the results were almost identical.  Using memory streams instead of the hard drives for temporary file storage also had little effect (+/- 1 second) on the results.

So there you have it, more threads is not necessarily always better.  I really could have told you that before I tried this little experiment, but I liked the process of producing tangible results showing that this is the case.