PDA

Ver la versión completa : El sonido chirría en ports



Puck2099
22/04/2006, 08:14
Hola,

Esto más que una pregunta específica es algo general dirigido a las personas que han portado/intentado portar cosillas a la GP2X.

Resulta que ya me ha pasado dos veces el tener problemas en el sonido al portar cosas (Pentagram y ROTT). Los efectos suenan, pero distorsionan y chirrían de una forma considerable, no es como pasaba antes al pasarle frecuencias incorrectas que "pitufaba", sino que suena, digamos, como un modem cuando marcaba el número.

En ambos casos se usan las SDL para el sonido, pero no creo que sea problema de ellas, pues he usado las "viejas" de la compo y las últimas de Paeryn y suena igual...

¿Alguien ha tenido algún problema similar y ha encontrado una solución o, al menos, intuye por dónde pueden venir los problemas?

Muchas gracias por la ayuda :brindis:

< - >
Bueno, creo que el Duke3D usa el mismo sistema de sonido que el ROTT, así que mañana veré si surgen los mismos problemas y si woogal fue capaz de arreglarlos :)

Saludos

BuD
22/04/2006, 09:21
Hola,

Esto más que una pregunta específica es algo general dirigido a las personas que han portado/intentado portar cosillas a la GP2X.

Resulta que ya me ha pasado dos veces el tener problemas en el sonido al portar cosas (Pentagram y ROTT). Los efectos suenan, pero distorsionan y chirrían de una forma considerable, no es como pasaba antes al pasarle frecuencias incorrectas que "pitufaba", sino que suena, digamos, como un modem cuando marcaba el número.

En ambos casos se usan las SDL para el sonido, pero no creo que sea problema de ellas, pues he usado las "viejas" de la compo y las últimas de Paeryn y suena igual...

¿Alguien ha tenido algún problema similar y ha encontrado una solución o, al menos, intuye por dónde pueden venir los problemas?

Muchas gracias por la ayuda :brindis:

< - >
Bueno, creo que el Duke3D usa el mismo sistema de sonido que el ROTT, así que mañana veré si surgen los mismos problemas y si woogal fue capaz de arreglarlos :)

Saludos
Menos mal, pensaba que era el unico que le sonaba asi. No sera cosa de Open2X?
En algun que otro programa que he hecho con la minilib he tenido ese problema. El sbagen tambien me chirria en segun que casos y el gngeo tambien cuando no da de si.
Se que no te soy de mucha ayuda, pero almenos confirmas que no eres el unico que le pasa...

EDIT: Antes de confirmar que el sonido de Duke3D funciona, vuelvelo a probar con el Open2X, no sea que el driver tenga la culpa.

hermes PS2R
22/04/2006, 15:37
Que chirrie no es nada raro teniendo en cuenta como trabaja el sonido.

Lo adecuado sería poder conectar un handler con el vector de interrupcion y escribir directamente el sonido en el buffer de DMA antes de enviarlo (y por supuesto, rellenar con ceros si no se completa el buffer)

En su lugar tenemos unas funciones orientadas a devices, que no son lo mas adecuado para trabajar el sonido precisamente y que se depende de programacion multihilo para poder manejar ese sonido (lo cual puede hacer que el hilo que maneja el audio se desfase y reproduzca algo de ruido, porque la DMA funcione en bucle y no haya dado tiempo a actualizar el buffer

Y otro detalle a tener en cuenta, es que los ports quiza esten acostumbrados a manejar un numero de samples mayor o menor que los que acepta el buffer de sonido de GP2X (por eso yo introduje unas modificaciones en la libreria de rlyeh) y en ese caso se pierden o no llegan suficientes samples.

BuD
22/04/2006, 17:57
Que chirrie no es nada raro teniendo en cuenta como trabaja el sonido.

Lo adecuado sería poder conectar un handler con el vector de interrupcion y escribir directamente el sonido en el buffer de DMA antes de enviarlo (y por supuesto, rellenar con ceros si no se completa el buffer)

En su lugar tenemos unas funciones orientadas a devices, que no son lo mas adecuado para trabajar el sonido precisamente y que se depende de programacion multihilo para poder manejar ese sonido (lo cual puede hacer que el hilo que maneja el audio se desfase y reproduzca algo de ruido, porque la DMA funcione en bucle y no haya dado tiempo a actualizar el buffer

Y otro detalle a tener en cuenta, es que los ports quiza esten acostumbrados a manejar un numero de samples mayor o menor que los que acepta el buffer de sonido de GP2X (por eso yo introduje unas modificaciones en la libreria de rlyeh) y en ese caso se pierden o no llegan suficientes samples.

Pero lo raro es que en la prueba que hice con la minilib lo unico con lo que trabajaba era con sonido, no tocaba ni video ni nada, y el codigo que generaba el sonido era muy sencillo, asi que dudo que no le diese tiempo a actualizar el buffer. [Ahhh]
EDIT: Me siento ignorado, debo ser una molestia. :(

hermes PS2R
23/04/2006, 02:28
Pero lo raro es que en la prueba que hice con la minilib lo unico con lo que trabajaba era con sonido, no tocaba ni video ni nada, y el codigo que generaba el sonido era muy sencillo, asi que dudo que no le diese tiempo a actualizar el buffer. [Ahhh]
EDIT: Me siento ignorado, debo ser una molestia. :(


Yo he notado cortes e interrupciones que se producen de forma interna (en el kernel, SO, o lo que sea).

El sonido si te fijas en la minilib, se hace escribiendo una serie de samples mediante la funcion write y antes de eso hay una llamada a la funcion de tu programa que se encarga de poner los samples en el buffer.

La funcion write funciona en modo bloqueo y eso hace que hasta que no se hayan escrito los samples (o se produzca un error) no retorne. El tema es que teoricamente, podría retornar escribiendo menos samples si el tamaño de los samples a escribir es demasiado grande (la funcion write devuelve el numero de bytes escritos y si es menor que los que le hemos pasado, debería hacerse una correccion en el buffer y escribir los samples que falten)

Aun así hay otro problema que es el modo en que trabaja la multitarea (que yo ignoro como va eso en la GP2X). En PS2 para cambiar de hilo se podía hacr directamente o usando un recurso que hacia que cuando se producia un instruccion de salto (en codigo maquina) se procedia a hacer ese cambio. Aqui es posible que funcione por mediacion de un timer o cuando se llama a una funcion de sistema y eso puede hacer que haya un desfase entre los datos de la DMA y los datos que escribes. No es algo que sea seguro al 100% si no una suposicion de porque a veces, hay problemas con eso. Habría que estudiarlo un poco y ver en que casos hay problemas y como se puede solucionar.