CapriceGP2x V0.01c

[hermes PS2R]

lee el mensaje anterior del sonido, sin el thread dedicado para el sonido y con lo q te he puesto va bien,y más rápido ya q el thread del sonido se come mucha cpu...

Vaya, acabo de editar el hilo anterior y me respondes sin leerlo, jeje (vamos desfasados como el sonido)

Ahi si que te doy la razón por completo: un hilo que se activa muchas veces por segundo, consume CPU (por eso incrementé el tamaño del buffer)

PD: Lo que necesitamos es interceptar el vector de interrupcion de la DMA de audio y veras como se acaban las tonterias: silencio cuando le falten samples y sincronizacion absoluta

[Franxis]

Hummm, no me gusta mucho la idea por dos razones: si el buffer se vacia y no escribes suficientes samples, se repetirá como un loro y tambien te podrias encontrar con el caso de que quieras escribir n samples y solo te admita n-2 por ejemplo.

El problema es de buffer interno ya que si no escribes samples, el sonido sigue reproduciendose (y eso provoca una demora que puede ir de 0 a lo que mida el buffer de la DMA) , Pero tampoco se si el que ha posteado arriba, esta hablando de juegos que tienen pistas de audio que ahi el problema es completamente DISTINTO

Si no escribo samples el sonido se corta. Lo veo cuando intento en el MAME hacer funcionar un juego q requiere más procesador, al menos con el código q he utilizado en el MAME...
con el codigo de antes del setfragment creo q cambias el tamaño del buffer de sonido, esta ajustado para q a 16500hz,16bit,mono suene perfectamente actualizando a 60 Hz.

salu2

[hermes PS2R]

Si no escribo samples el sonido se corta. Lo veo cuando intento en el MAME hacer funcionar un juego q requiere más procesador, al menos con el código q he utilizado en el MAME...
con el codigo de antes del setfragment creo q cambias el tamaño del buffer de sonido, esta ajustado para q a 16500hz,16bit,mono suene perfectamente actualizando a 60 Hz.

salu2

Oki, lo voy a probar antes de irme pal sobre, aunque yo utilizo 44100hz.

[hermes PS2R]

Err... mis resultados con las pruebas usando el metodo de Franxis.

Antes de nada, tengo que decir que yo partía de una modificacion de la minimal library de rlyeh 0.B, que usa de base la modificación que introduje en el ultimo gp2xengine (buffer grande y procedimiento para fragmentar escrituras en caso de que el device de audio no 'trague' mas, etc)

Fale, la novedad que introduje en el emulador de spectrum, es la posibilidad de retornar el numero de samples que enviamos desde la función de tratamiento (lo cual es mas logico que limitarse a recibir un numero de samples y tener que lidiar con eso).

El sistema de audio que utilizo en el emu, consiste en un array de punteros que apuntan a una serie de bufferes del tamaño que utiliza el spectum para devolver el audio durante un frame al cual añado un campo para conocer si el buffer contiene audio util o no.

El audio está ajustado a 44100Hz, mono y el retorno de la funcion lo tengo fijado a 11025 samples, es decir: 1/4 de segundo.

Con esto consigo tener una velocidad estupenda en el emulador y el audio me va bien, o eso pienso.

Probando el metodo de Franxis (eliminando el hilo e incluyendo una funcion que encapsula la escritura de samples) me enciuentro que el emulador se queda clavado y va como el culo.


¿por que? Pues muy simple: porque no puede escribir todos los samples y entonces se queda esperando a que la DMA de audio vaya tragando samples (supongo)

Si limito la escritura a un valor mas 'adecuado' el sonido va cortado y el emulador pierde bastantes frames... sencillamente, el metodo es una mierda.

Pero vamos, existe un pequeño truco para evitar que el device se quede clavado: consiste en abrirlo con la opcion O_NONBLOCK.

Así se procede a una escritura asíncrona y aunque no implementé todo el mecanismo para que el audio se reprodujera correctamente, si que pude apreciar que el emulador iba mas lento que cuando usaba el thread de las minimal.

Eso me pasa incluso con las librerías estaticas y la verdad, no me parece nada raro ya que supongo, cada vez que haces un write, se pone en marcha un mecanismo de semaforos y se cambia al thread que controla al device, por lo que al final es un metodo mas lento que tener un thread que se suspende devolviendo el control a nuestro hilo principal y que en el momento apropiado, retorna para pedirnos nuevos samples.

Así pues, el resultado de mi experimento es bastante negativo: es mucho mas rapido un hilo que se activa 4 veces por segundo devolviendo el testigo al hilo principal de nuestra aplicacion cuando toca esperar, que llamar 50 veces a esa funcion (aunque sea sin bloqueo) o tener que reinventar la rueda para hacer lo mismo que queremos evitar.