Scripting: audio playback script

klss · 01-13-2009, 05:27 PM

Hi folks.

I am wondering if I could make myself clear with the headline for this
thread. Anyhow I try to be a bit more descriptive.

Below script extract is supposed to outline my challenge.
I'd like to play multiple audio files sequentially. I'll store them
all on /dev/shm during playback.
The upsampling with sox I don't want to do in realtime. This is actually the issue causing all this.
The sox sample rate conversion takes in the range of 10 to 20 seconds
depending on the file size.

The exercise: I 'd like to avoid such a long gap between the playback
of two songs, which obviously will exist if I run the script as outlined below.

I would like to convert the 2nd file of the filelist in $file in the background while the first playback is started/ongoing.
And I always want to have max 2 files + one temporary file on the ramdisk.

How would you guys do this?

THX a lot.

Code:

file=$1  # can be a directory
tmpfile=foo.wav
musicdir=`pwd`
ramdir=/dev/shm

ls -1 "$file" | grep 'wav' | sort | while read I ; do
  cp -f "$I" $ramdir
  cd $ramdir
  sox  "$I" $tmpfile rate -v -s 96000
  mv $tmpfile "$playfile"
  play "$playfile" 
  rm "$playfile" 
  cd $musicdir
done

blackhole54 · 01-14-2009, 01:41 AM

Quote:

Originally Posted by klss

I would like to convert the 2nd file of the filelist in $file in the background ...

That is exactly the right way to say it!

Except I think it would be easier if the play command was in the background instead.

When you end a command with a single ampersand (&) it will be "run in the background." So you might want to do something like the following. (Warning: I have not tested/debugged this script.) I have "niced" the sox command in hopes that it doesn't take too much processor time away from the play command. (If you have two processors or a sufficiently fast processor this may not be an issue.) If this is not enough to get smooth palyback then you may need to look into executing your play command with real-time priority -- if it isn't already. (I can't help you with that).

Code:

file=$1  # can be a directory
tmpfile=foo.wav
playfile=bar.wav
musicdir=`pwd`
ramdir/dev/shm

ls -1 "$file" | grep 'wav' | sort | while read I ; do
  cp -f "$I" $ramdir
  cd $ramdir
  nice sox  "$I" $tmpfile rate -v -s 96000
  wait
  mv $TMPFILE "$playfile"
  play "$playfile"  &
  cd $musicdir
done
rm "$playfile"

The wait statement will wait until all background processes have complete. (There is a danger of the script hanging if for some reason the background process does not complete. Handling that would make for a more complicated script. You can still bail out with Ctl-C) See the bash man page for more details.

I also moved your rm $playfile to after the loop. Maybe not necessary, but it doesn't hurt anything either. The mv command, when it executes, will simply overwrite any old $playfile that may exist.

klss · 01-14-2009, 03:34 AM

Works flawless. You made my day!

BTW: My playback application is running with SCHED_FIFO rt-prio.
I experience no impact of the additional upsampling process at all.
In the original script I also decode flacs non-realtime.

Decodeing flacs and upsampling at this quality (maximum) causes >50% processor load if done in realtime. Now I am down to about 1%.
There is obviously much less system impact and absolutely no compromise on sound quality.

The only difference to realtime processing is >10s for the startup

Again THX a lot.

Cheers

klss · 01-14-2009, 05:27 AM

Hi there.

I did some testing.

One thing I caught now by introducing the "wait".

If $file is a single file, "while" drops out and the script gets finished.
play keeps running in background though.
The script actually should stop as soon as the playback stops.

I tried this

Code:

file=$1  # can be a directory
tmpfile=foo.wav
musicdir=`pwd`
ramdir=/dev/shm

ls -1 "$file" | grep 'wav' | sort | while read I ; do
  cp -f "$I" $ramdir
  cd $ramdir
  sox  "$I" $tmpfile rate -v -s 96000
  wait
  mv $tmpfile "$playfile"
  play "$playfile" & 
  cd $musicdir
done
wait
#rm "$playfile"

The 2nd wait doesn't have any impact!?!? It is probably because the "while" loop runs in a subshell and wait can not
access this subshell. I tried wait [PID] outside the while-loop which prints "wait: pid 19472 is not a child of this shell"

Code:

file=$1  # can be a directory
tmpfile=foo.wav
musicdir=`pwd`
ramdir=/dev/shm

ls -1 "$file" | grep 'wav' | sort | while read I ; do
  cp -f "$I" $ramdir
  cd $ramdir
  sox  "$I" $tmpfile rate -v -s 96000
  wait
  mv $tmpfile "$playfile"
  play "$playfile" & 
  cd $musicdir
done
wait `pgrep -f play `

Is there a solution to it? The wait causes another issue. Before, I was switching songs with ctrl-c. This won't work anymore.
I have the feeling that I won't get it done by using wait.

How about this?:

How do I get access to the 2nd field in $file while the while-loop is still working on the 1st file ?
This way I could start upsampling the 2nd file, if there is one, in background while playing the prior field.

Cheers

klss · 01-15-2009, 04:12 AM

I now introduced an array
This makes it possible to easily access the 2nd resp the next track to do the upsampling in background,
while the first track is playing in foreground.

Cheers

blackhole54 · 01-16-2009, 02:17 AM

Glad you got it working to your satisfaction.

You were correct about why the second wait did not work.

FYI, when you need to send input to a while loop but need it to run in the current shell (instead of a subshell), you can:

Code:

while ... ; do

...

done < file

In this case you would need to create a temporay file first that contained your playlist and then run the while loop.

Bash has process substituion which is supposed to eliminate the need for the termporary file, but I can't get it work with while loops and I don't know why. If it worked, it would look somehting like:

Code:

while ... ; do

...

done <(ls -1 "$file" | grep 'wav' | sort)

When I try that I always get an error, although it will work as input for simple commands. Maybe somebody can explain that to both of us ...