Sistema de grabación por celulares
Informe Técnico Interno
Miguel Martínez Soler
Laboratorio de Investigaciones Sensoriales - LIS Facultad de Medicina
Universidad de Buenos Aires
Control de cambios
Fecha Comentario Autor
Propósito
Este documento tiene como propósito volcar la información técnica relacionada al desarrollo de un sistema de grabación por celulares, en el marco del proyecto PID 35891 de FonCyT. Mediante el mismo, se pretende construir un repositorio unificado de la información técnica del proyecto, que resulte útil a quienes a partir de ahora participen en su desarrollo y sirva como punto de partida para posibles proyectos futuros.
Introducción
El proyecto PID 35891, “Desarrollo de técnicas para el reconocimiento del hablante” tiene como objetivo introducir el desarrollo de las técnicas de reconocimiento del hablante para su aplicación a nivel forense. El reconocimiento automático del habla y del hablante, es un campo multidisciplinario con especial vinculación con las ciencias de la computación, el reconocimiento de patrones, la inteligencia artificial y la fonética acústica.
Uno de los objetivos específicos del proyecto es la creación e implementación de un corpus de voces de hablantes, tomados tanto en forma directa como por el canal telefónico, de acuerdo a los lineamientos de Speech-dat SALA Europeo [3].
Con el fin de acelerar la adquisición de datos para el corpus mencionado se optó por desarrollar una aplicación de grabación automática de llamadas que funcione en una plataforma de telefonía celular. Esta decisión fue tomada teniendo en cuenta que la institución adoptante del proyecto (Gendarmería Nacional) posee una infraestructura de comunicaciones de bajo costo que abarca todo el país.
Para su implementación, se seleccionó la plataforma de teléfonos celulares basados en sistema Symbian, en el entorno de desarrollo Carbide, utilizando como lenguaje de programación C++.
El resto del informe se estructura de la siguiente forma: En la sección que sigue, se detallan los requerimientos y las plataformas de desarrollo utilizadas. Luego, se describe el diseño del sistema resultante, detallando seguidamente su implementación. Finalmente, se presenta el modo de uso del sistema y los recaudos que se deben tener antes de ponerlo en funcionamiento.
Requerimientos y Plataforma de Desarrollo
Para cumplir con los objetivos propuestos en el plan del proyecto, el sistema de grabación planteado debía ser capaz de cubrir los siguientes requerimientos::
1. Atender automáticamente llamadas entrantes.
2. Presentar un prompt de bienvenida, y realizar preguntas al interlocutor con los prompts adecuados.
3. Grabar y almacenar las respuestas de los interlocutores, para su posterior análisis. Los puntos 1 y 2, son relativamente fáciles de implementar en la mayoría de las plataformas
de telefonía celular actual. El punto 3, sin embargo es un poco más difícil de alcanzar, puesto que la mayoría de las especificaciónes de sistemas operativos para teléfonos celulares no contempla la posibilidad de grabar llamadas en curso. Dentro de las opciones más comunes, unas de las pocas plataformas que permiten implementar este requerimiento son Android y Symbian.
Los sistemas basados en Android tienen la desventaja de que, aunque la especificación del sistema operativo prevé la funcionalidad necesaria para grabar llamadas entrantes, son muy pocos teléfonos celulares que la implementan (al momento de escribir este informe, sólo tenemos noticia de su funcionamiento en teléfonos Samsung Galaxy). Symbian por otro lado permite grabar llamadas en curso hasta la versión S60 3rd Edition.
Gracias a la compatibilidad con versiones anteriores, es posible usar estas características en versiones posteriores del sistema, siempre y cuando se utilice el framework de la versión mencionada anteriormente.
No es posible, sin embargo, grabar llamadas en curso utilizando las librerías estándar de Symbian. Para conseguirlo, es necesario utilizar como componente adicional: el plugin Audio
Proxy Server.
El sistema que se describe en este informe fue implementado sobre Symbian S60 3rd Edition, utilizando Audio Proxy Server. A continuación se describen en forma breve las características de esta plataforma.
Symbian [2] es un sistema operativo diseñado para ser utilizado en teléfonos celulares que se adapta consecuentemente a las condiciones particulares que presentan estos dispositivos. Normalmente, un teléfono con sistema Symbian cuenta con una unidad de procesamiento de 32 bits cuya velocidad es inferior a la de una computadora de escritorio. Tanto el sistema operativo como los programas de usuario se encuentran cargados en memoria no volatil ROM o Flash, a la que se puede acceder de forma directa o por archivo, ya que se encuentra mapeada como unidad de disco. Esto permite que los programas se ejecuten in-place, es decir, sin cargarse a memoria RAM como ocurre en una PC. Los archivos y programas se almacenan en esta memoria o en una expansión de memoria Flash, normalmente ubicada en tarjetas de memoria externas. Existe también una memoria RAM no volátil en la que se encuentra la memoria de trabajo de los programas activos, incluyendo el sistema operativo. En todos los casos, comparando con una PC, ell tamaño de la memoria es limitado. Sin embargo, esta puede expandirse utilizando tarjetas de memoria flash.
Los dispositivos de entrada y salida son muy específicos y cubren funcionalidades típicas de un teléfono celular (pantallas táctiles, manos libres, puertos infrarojos, Bluetooth, etc). Los teléfonos, además, funcionan normalmente con alimentación provista por una batería.
Todas estas características hacen de Symbian un sistema operativo muy especializado, en el que los recursos son limitados, sobre todo en cuanto al procesador y la memoria. No hay discos rígidos y por lo tanto no hay memoria virtual. Adicionalmente, el manejo de la energía es crucial.
Fig 1. Diagrama de capas de la arquitectura symbian.
El sistema operativo cuenta con un kernel que tiene acceso privilegiado a los recursos de hardware. Los demás programas deben hacer llamadas a este para solicitar acceso a los recursos. Estos programas, llamados programas de modo usuario, pueden ser servidores, aplicaciones, o motores (engine en inglés).
Una aplicación es un programa con una interfaz de usuario. Cada aplicación corre en un sistema diferente. Los servidores son programas sin interfáz de usuario que prestan servicios a programas cliente a través de un API (application programming interface). Estos clientes pueden ser aplicaciones u otros servidores. Los servidores corren como procesos separados, independientes de los clientes.
Un motor es la parte de una aplicación que maneja sus datos. Si bien no es obligatorio utilizar motores, se considera una buena práctica de ingeniería de software separar el control de la interfaz. Esto se puede implementar a nivel de código, como un módulo de código separado, o mediante una librería de enlace dinámico (DLL).
En Symbian, los procesos se ejecutan siguiendo una planificación multitarea apropiativa. Cada proceso puede tener uno o más hilos de ejecución que corren siguiendo la planificación del sistema operativo. Aunque cada hilo de una aplicación corre como un proceso separado, todos ellos tienen acceso al mismo espacio de memoria.
Diseño del Sistema
La arquitectura del sistema de grabación por celulares sigue los lineamientos de la implementación descripta en la especificación de Audio Proxy Server [1]. APS utiliza una arquitectura cliente-servidor para comunicarse con los recursos de audio del sistema S60. De acuerdo a la especificación, las principales funciones del cliente APS son:
1. Establecer un canal de comunicación con el servidor APS. 2. Inicializar la sesión del servidor en el hilo principal.
3. Inicializar el hilo destinado a dispositivos de entrada.
4. Habilitar la comunicación entre hilos de entrada y salida, como así también las aplicaciones clientes, mediante colas de mensajes.
5. Preparar los dispositivos de grabación y reproducción para su funcionamiento, mediante el pasaje de parametros como el tipo de codec, el número de canales, la tasa de muestreo, etc.
6. Enviar comandos especiales para configurar los codecs soportados. 7. Comenzar a reproducir y/o grabar.
8. Parar las sesiones de reproducción y grabación. 9. Activar y desactivar el parlante del teléfono.
El servidor APS se inicia luego de que la aplicación cliente realiza un pedido de conexión. Luego de la inicialización, el servidor procesa los pedidos que llegan a través de la sesión del cliente APS. Las principales responsabilidades del servidor APS son:
1. Crear los hilos de ejecución para reproducción y grabación.
2. Manejar los pedidos de clientes y controlar la reproducción en el hilo principal. 3. Procesar en el hilo de grabación las muestras de audio codificados.
Fig 1. Diagrama de asociación de Audio Proxy Server
Partiendo del ejemplo provisto por la documentación de APS, se desarrolló una aplicación cliente que cubre los requerimientos antes mencionados. Para su implementación se programó en lenguaje C++ usando Carbide como entorno de desarrollo. La aplicación se desarrolló y testeo en un teléfono Nokia N95 mini especialmente destinado para la grabación del corpus. La aplicación consiste en un contestador automático de llamadas que presenta prompts al usuario y graba las respuestas de este utilizando formato a-law con una tasa de muestreo de 8KHz. La informacion queda grabada en una memoria tipo SD para su posterior análisis y procesamiento.
Modo de uso
Al iniciar la aplicación se presenta una ventana de log en la que se puede ver, luego del proceso de inicialización, que el teléfono está listo para recibir llamadas.
La aplicación atiende automáticamente las llamadas, presenta los prompts, guarda las respuestas e interrumpe la llamada una vez la grabación ha finalizado. En el caso de que la llamada se detenga antes de finalizar el proceso de grabación la aplicación vuelve al estado inicial, esperando una nueva llamada. Cuando esta se produce, empieza un proceso de grabación completa desde el principio.
La cantidad de promtps y el tiempo disponible para las respuestas son fijos y están definidos en el código fuente. En caso de querer modificar estos valores es necesario compilar una aplicación nueva.
Los archivos de grabación se numeran secuencialmente con número de hablante y número de respuesta, finalizando con extensión .esa (por ej. 10-5.esa). Estos archivos de audio se encuentran en la tarjeta de memoria SD del celular, junto a los archivos correspondientes a los prompts que debe reproducir la aplicación. La ruta completa para los archivos de prompts es “E:\sounds\corpusbuilder” mientras los archivos correspondientes a los prompts se encuentran en “E:\sounds\corpusbuilder\prompts\”.
Referencias
[1] Audio Proxy Server (APS) 2.4 Design Specification. Nokia Corporation. Accesible desde http://wiki.forum.nokia.com/index.php/Audio_Proxy_Server
[2] Harrison R. Symbian OS C++ for mobile phones. John Wiley & Sons Inc; 2007. [3] Gurlekian, J., Colantoni, L., Torres, H., Rincón, A., Moreno, A., Mariño, J.: Database for an automatic Speech Recognition System for Argentine Spanish. In: Proc. Of the IRCS Workshop on Linguistic databases, pp. 92-98, Pennsylvania (2001)
