Try commenting out line 372 of TranscodingHelper:
$command .= (Slim::Utils::OSDetect::OS() eq 'win') ? '' : ' &';

I am not sure why we launch these processes into the background like that, it doesn't seem to be necessary.

So that change does keep multiple ALAC processes from starting, but introduces other artifacts... now every time you hit Next there's a good 10 second pause as the first ALAC process dies before the next one starts up. While this is occurring, there's no audio at all ... unless you've got your system hooked up with Optical audio, in which case it will keep streaming audio until the buffer clears out. (at least thats what it seems like). 

I guess we know why the '&' was added.

Andy,
  Could we set an option that ALLOWS a user to say 'I have a slow system... If I'm transcoding music, do not start transcoding a new song until the previous transcoding process has died. It introduces latency, but also solves some performance issues for slow systems. 

I experience this problem or a similar problem as well.

When I start playing a playlist or when I skip to the next or previous song, I hear the new song for about one second. Then playback stops for 15-30 seconds before the song picks up again.

When I play an entire album or playlist without skipping a song, this only happens with the first song I play or if I skip songs, subsequent songs play without stutter.

When I check the process list, I see two alac instances running at the same time. One is consuming the usual amount of CPU power, the other, older process, runs on significantly less CPU. As soon as I kill this older process, playback picks up within a fraction of a second. Since the CPU still has some cycles left, I don't think the reason for this stutter is because once process hogs the CPU, but that the two processes somehow interfere with each other.

My setup for SC is a Synology CS-407 NAS with latest firmware (722). This box has a 500 MHz CPU and 256 MB RAM running Linux (kernel 2.6). I'm running SC 7.2 and have not seen this problem on 7.1 - it's so annoying I would remember this. I've tried both running SC using SSODS (oinkzwurgl.org) and using the new package that Synology supply themselves. My client is a Squeezebox Receiver with Duet controller.

All my songs are in Apple Lossless format and I usually transcode to WAV since I only require one transcoding step then. I've verified that the problem also appears when transcoding to FLAC, however. 

I should add that stutter on first playback of a song only happens, if I've played songs before. It does not happen after initial startup (no alac instance to die then).

I did a couple of tests and I feel obliged to clarify my comments, since some of my observations were plain wrong.

First of all, this issue also appears with SC 7.1.

Second, if I switch to ALAC->FLAC transcoding, the problem is gone. Even if I'm impatient and skip several songs at once, I can skip 3, 4 songs before a gap appears. That's even with volume normalisation and cross-fading turned on. Several alac processes are then hogging the CPU with roughly 20-40% CPU cycles each.

If I use ALAC->WAV transcoding, however, applying the above patch or not applying it doesn't make a difference. A song will play for roughly one second, then a gap of 10-20 seconds shows up before playback resumes. Maybe this is because (uncompressed) WAV fills up the buffer of my SB Receiver much quicker than (compressed) FLAC.

So it seems that on my ARM/500 MHz/128 MB NAS, ALAC->FLAC transcoding is the best solution for me, even if it takes a couple of cycles more. The reason why I originally chose ALAC->WAV was because it uses less CPU.

What I additionally noticed when observing the process table is that on skipping a song, flac instantly dies. Maybe there's a way to make alac die sooner as well? That would help slower systems.

Is this improved at all by the recent transcoding changes?

Update hours

I do not believe that this is still an issue with the change from using alac to faad. Please reopen if it is.