Your suggestions have provided the right answer!

I'm glad to help, but unfortunately I'm also confused by your post. Maybe it's because I haven't fully understood all of your requirements. So far, I get that you want to play a sound to the user, but also want to be able to stop the playback at any time, is that right? In that case, I'm not sure how the "Option 1" script helps, and how it's different from the code I showed? As for the "Option 2" script, I understand you want to monitor the state of the subprocess - that's an understandable requirement, although there are often better solutions than polling, but that depends on other things like if this is a GUI app or something else, and how playing a sound fits into the "bigger picture" of your application's purpose and design? If I've missed something, please explain. <update> In my previous node, I admit I did not consider that you may want to poll the state instead of just block until the subprocess is done, but again, that's just another good reason to explain all of the requirements and the context :-) </update>

I'm sorry but I have to say I don't agree with the way you're going about using the module. First, you're reaching into the IPC::Run object's undocumented internals. They may change without notice across different versions of the module, breaking your code. Also, your assumptions, like that the "KIDS" array only has one element, might not always be true. Second, I don't see how the sleep 5; helps in the first script. Third, I said that ->finish calls waitpid under the hood, but now you're using both. The same goes for $h->signal('INT') - you're signaling a process that at that point should already be gone. Both are unnecessary, and the reason I mention this is because it makes me suspect you may have misunderstood something in their use, or even the control of subprocesses in general (perhaps a close read of perlipc is a good idea).

Modules like IPC::Run wrap the underlying system calls (like waitpid) in a "nicer" interface so that you don't have to use the lower-level calls. Sure, sometimes (rarely!) the modules don't support everything you need, and hacking their internals becomes necessary. But I strongly recommend looking at the API the module provides before looking into its internals!

For your "Option 1" (block until the subprocess is done), the "right" way to use the module is the code I showed (just remove the Time::HiRes stuff). For your "Option 2" (poll the subprocess state), study the IPC::Run documentation and you will find the pumpable method:

use IPC::Run qw/start/;
my $h = start ['play','-q','/tmp/sound.wav'];
while ($h->pumpable) {
    print "waiting...\n";
    sleep 1;
}
$h->finish;
print "finished!\n";
[download]

See how much nicer that is, without having to muck about in the object's internals? Here, I've put that together with a signal handler that will catch SIGINT (usually Ctrl-C) and cleanly signal and terminate the subprocess:

use IPC::Run qw/start/;
my $h = start ['play','-q','/tmp/sound.wav'];
{ # block for local $SIG{INT}
    my $run=1;
    local $SIG{INT} = sub {
        print "caught SIGINT, stopping...\n";
        $run=0;
        $h->signal('INT');
    };
    while ($run && $h->pumpable) {
        print "waiting...\n";
        sleep 1;
    }
}
$h->finish;
print "finished!\n";
[download]