Speech Served Here : Tuning, MSS 2007

Direct access to audio in the Speech Server 2007 database

brandontyler — Fri, 31 Aug 2007 14:42:11 GMT

Sent to you by Brandon Tyler via Google Reader:

Direct access to audio in the Speech Server 2007 database

via Search results for '"Speech Server"' by spokenword on Aug 30, 2007

Here is a sample program that illustrates the principle of extracting a single audio file from the audio tables of an OCS 2007 Speech Server log database. This sample is governed by the Microsoft Permissive License as defined at http://www.microsoft.com/resources/sharedsource/licensingbasics/permissivelicense.mspx.

NOTE: you only need to do this if you are interested in accessing session audio (prompts as well as recognitions) outside of the Analytics and Tuning Studio, i.e. you have a need for programmatic access to session audio. Otherwise use Analytics and Tuning Studio to listen to recognition or session audio (see here), or MssContentExtract to extract recognition audio.

As written, the compiled application takes three parameters:

<database name on localhost>
<audio type: 'prompt' | 'reco'>
<DB audio id of the audio data to convert>.

The result of execution is a wav file of the form: 'reco_id.wav' or 'prompt_id.wav'.

Obviously, generating a single file containing the prompt and reco audio of an entire session requires further work to mix and concatenate the individual wav files that make up the call.

Note: ensure that any projects using this file link to the Speech Server common library (i.e. add the following line to your project file):

<ItemGroup>
<Reference Include="Microsoft.SpeechServer.Common, Version=2.0.3400.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
...
</ItemGroup>

Things you can do from here:

Visit the original item
on Search results for '"Speech Server"'
Subscribe to Search results for '"Speech Server"' using Google Reader
Get started using Google Reader to easily keep up with all your favorite sites

Extracting session audio from OCS 2007 Speech Server logs

brandontyler — Fri, 31 Aug 2007 14:42:08 GMT

Sent to you by Brandon Tyler via Google Reader:

Extracting session audio from OCS 2007 Speech Server logs

via Working the Spoken Word by spokenword on Aug 31, 2007

The ability to extract the audio for an entire call (both prompts and recognitions) from the Speech Server 2007 logs is a really useful feature for a number of analysis and tuning scenarios. Since the topic has surfaced a few times on the Beta newsgroups, here's a summary of how to do it.

1. Ensure your logging parameters for the server are set (via the Trace Logging tab in the Administration Console) to log Application Events and All audio for: 100% of calls.
2. When you import the log data into the database with the MssLogToDatabase utility, be sure to specify the flag /audio:session.
3. In Analytics and Tuning Studio, connect to the database and in the Session List View or Session Detail View select the call that you want to hear. Hit the Play Session Audio button to play it back using your default .wav player, or hit the Export Session Audio button to export to file.

Some notes:

1. The logging of prompt audio is not available with TIM deployments of Speech Server (i.e. you need to be running a VoIP gateway).
2. The prompt audio as recorded does not take account of any dynamic changes to timing or volume. (So if, for example, the caller accelerated or decelerated playback while the prompt was underway, you won't hear the changes, and you may notice timing mismatches on the concatenated output file. You can check for these cases by looking for the relevant event signalling the prompt rate change in the session details.)
3. Some scenarios may call for access to the audio data in environments outside Analytics and Tuning Studio. For some sample code that illustrates how to extract the audio programmatically from an OCS 2007 database, see this article. (Extracting session audio is not possible with the command line utility MssContentExtract.exe, which be used only for extracting recognition audio.)

Things you can do from here:

Visit the original item
on Working the Spoken Word
Subscribe to Working the Spoken Word using Google Reader
Get started using Google Reader to easily keep up with all your favorite sites

ETL File Management and DTS Import Tips

brandontyler — Fri, 18 May 2007 13:56:00 GMT

I have been working with lots of ETL files lately and thought I would pass on some tips I have found in the documentation (ETL Files are still around in OCS 2007 Speech Server so this is still applicable):

Compress .etl files to the Zip Archive file format. By their nature, .etl files contain a lot of repetitive content, which makes file compression very effective. Compressing .etl files to the ZIP format will both cut disk space usage and reduce the network bandwidth needed when copying files to other computers as described in the following bullets.

Before you FTP those ETL files from the customers site zip them up! It will save you time.

Configure Microsoft Speech Server (MSS) to write .etl files out to a local drive on the MSS computer. It is preferred that this drive be separate from both MSS and the operating system. There are two issues here. First, if the operating system drive gets full MSS won't have enough space, which might actually cause calls to fail. Second, logging to a local drive is more efficient. Runtime performance of Enterprise Instrumentation Framework (EIF), and therefore MSS, will suffer if the server has to write all the log file events to .etl files across a network.

These ETL files get very large. Set aside a large drive just for the ETL files and make sure it has a fast write speed.

Importing .etl files to the SQL database directly from the MSS computer may impact MSS performance. To avoid this, before importing .etl files, copy them to a computer other than the MSS computer. To minimize performance impact, the copy operation should be performed off-hours; and by a low priority scheduled task. In order to give the MSS computer control over the task priority, the task must run on the MSS computer. In other words, the MSS computer should push the files onto the destination computer using a low priority scheduled task.

Most customers I have seen do this. I like the thought of having the MSS computer controlling the transferring of the files so that it does not affect performance. Try to transfer them to the SQL Server computer that will be performing the DTS transfer. When the DTS processes is running it is importing the call data from files that are local and not over a network.

Users should choose filters with the smallest number of events possible to meet their needs. If users import audio and all events, the import can take an extremely long time.

You don't always need all the events do you? Try filtering just these 4 events: QASummaryEvent, CallStartedEvent, CallEndedEvent, and CallRejectedEvent