Horst von Brand escribió: > Luis Eduardo Vivero Peña <[EMAIL PROTECTED]> wrote: > > El mié, 28-12-2005 a las 16:14 -0300, Luis Eduardo Vivero Peña escribió: > > > > Una posibilidad es que me ponga a ver si esta funcionando xmms, mplayer, > > > realplayer (ps -fea | grep xmms && ps -fea | grep realplay, etc), y > > > antes de reproducir la alarma mate el proceso en cuestion. Pero no creo > > > ke sea una buena solucion, ya que si esta corriendo un software que no > > > esta en la lista de los programas posibles a 'matar', entonces no > > > funcionara. > > > > > > Alguna idea para liberar el dispositivo de sonido de otra forma? > > > > Ah se me ocurrio que puede ser con lsof /dev/dsp , pero de ahi tengo que > > sacar el PID del proceso... > > Los distintos ambientes traen "servidores de sonido" que permiten > multiplexar varias fuentes hacia un solo dispositivo.
Ejemplos de esto son esound y arts. La idea es que configuras xmms y mplayer para que en lugar de escribir directamente a /dev/dsp, lo hagan a traves de esound/artsd. Y tu programa de tocar sonido debe hacer lo mismo. Otro asunto es que con tarjetas de sonido decentes, varios procesos pueden escribir directamente y por lo tanto suenan simultaneamente sin bloquearse. Pero no es tu caso. -- Alvaro Herrera Developer, http://www.PostgreSQL.org "Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible" (Calvin a la TV) From [EMAIL PROTECTED] Thu Dec 29 14:47:17 2005 From: [EMAIL PROTECTED] (Tipler) Date: Thu Dec 29 14:40:24 2005 Subject: Sobre perfomance de Mysql ... In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> > Quizas el servidor web esta configurado para muchos procesos > concurrentes y cada uno guarda conexiones persistentes a la BD. Eso es > tipico con Apache y PHP (pg_pconnect o su equivalente MySQL), si > MaxChilds de Apache es mayor que el max_connections de Postgres (o su > equivalente de MySQL). .. estuve mirando y realice cambios de ese tipo, justamente para que no suceda. Pero aún así el "too many connections" en momentos de mucho trafico el mysql se vuela ... .. como estoy realizando pruebas a ciegas, sin conocer el motivo real del problema, es por eso que les consultaba sobre alguna herramienta que me permitiera analizar lo consultado a la DB (los querys más pedidos, el tiempo de ejecución, cuantas conexiones abiertas simultaneas, etc). gracias. Tipler
