What's new in ACS 2.2

Thanks Section

Introduction to ACS Programming

Note: the technique described below is only useful when the input sources have different audio parameters (sample rate, number of channels, number of bits per sample). In case when all the inputs have the same audio parameters you may want to use TInputList component instead.

In some cases you may want to start the next audio task automatically right after the previous task has been finished. Suppose you build an audio player with a kind of playlist. You want the files in the playlist to be played one after another.

When the current file playback or other output operation is finished output component generates OnDone event indicating it has finished current output operation. The problem is however that generally you cannot call output component’s Run method from the component’s own OnDone event handler to play the next file. You could use messages or timers to bypass this problem but there is another, purely ACS way to do it.

Use two output components instead of one. In our example you can use two AudioOut components in your player application. When you start playing the playlist the first AudioOut component takes the job. After the first audio file playback is finished the first AudioOut component generates the OnDone event. In this OnDone event’s handler you select the second file from the playlist and make the second AudioOut component to play the file by calling its Run method. When the second AudioOut component has finished the playback it also generates the OnDone event. In this OnDone event’s handler you turn back to the first AudioOut component and make it to play the third file from the playlist and so on. You can find a working example of this technique in the Audio Player Demo.

This topic is thoroughly described in the farther documentation, but people send me so many questions on it that I decided to put an additional explanation here.

The actual input and output is performed in ACS by threads. It is natural to put the thread into the suspended state when it has no job to do and resume the thread when it has one. However, when developing under Kylix IDE suspending and resuming threads may be inconvenient since every time such an operation is performed, signals are emitted. These signals are trapped by the IDE, and the program execution stops. That is why SuspendWhenIdle property has been introduced. The idea behind this property is that when you develop an application under Kylix, you set this property to False, so that the ACS threads don’t get suspended. When you’re preparing the final release, you set this property to True which makes the threads to be suspended when there is no job for them and thus reduces CPU load.

Under Linux the default value of SuspendWhenIdle property is False so threads don’t get suspended by default. Under Windows, where there is no problem with signals the default value of this property is True and there is no need to change it.

Two following pictures show the CPU load with SuspendWhenIdle set to False and True respectively. The high plateau on the right side of the first picture corresponds to the high CPU cycles consumption by the idle thread not being suspended.

Starting from the ACS version 2.2 most of the components that have Input property (output and converter components) allow assigning new input on the fly (i.e. while the component is doing playback). It is important to remember that when changing input on the fly, new input audio stream parameters must be thhe same as the old ones. Note that TAudioProcessor Component doesn't allow modifing Input property while it is playing. InputList component allows modifing all input items at anytime except the item, currently being played. You can switch to other InputList's item on the fly by changing the components CurrentInput property.

This section explains how to avoid some errors that are most often encountered by the programmers beginning to use ACS.

Under Linux the shared libraries required by ACS (Ogg Vorbis libraries and the like) may have different filenames and locations depending on Linux distro. To simplify libraries linking ACS uses dynamic linking and run-time libraries search. This search however can slow down appliactions sturtup. If you develop an application for a particular distro and you know where exactly some library is placed and what its file name is you may disable run-time search. This requires you to provide full library name and disable SEARCH_LIBS directive in the appropriate unit. Let's for example look at VorbisFile unit. If the run-time search is anabled, the corresponding fragment of the unit looks like this:

{$IFDEF LINUX}
  LibvorbisfilePath =  'libvorbisfile.so*'; // search mask
  {$DEFINE SEARCH_LIBS}  // directive
{$ENDIF}

In order to disable run-time search change this fragment to:

{$IFDEF LINUX}
  LibvorbisfilePath =  '/usr/lib/libvorbisfile.so.0.1'; // exact file name
  // {$DEFINE SEARCH_LIBS}  // directive disabled
{$ENDIF}