Liberar Objetos II

[[Lepe]]

Si es un Tipo de datos, debe declararse con la "T" delante ej: TVorbisIn
Si es una variable, se declara sin "T" ej: VorbisEntrar.

El problema es que todo tiene delante la "T" y no se sabe si estas accediendo a un tipo de datos o bien a una variable. (más o menos se intuye, pero se pueden cometer errores muy graves al hacerlo de esta forma), te recomiendo, por tu bien , que modifiques el código.

Lo que no me queda claro es por qué usas varios VorbisEntrar, VorbisEntrar2, etc, ¿tienes varios ogg cantando al mismo tiempo?

Se supone que no, ya que es un reproductor de canciones, por tanto una va detrás de otra; entonces, el evento para decrementar el contador, se puede aprovechar para cambiarle el nombre de archivo al mismo VorbisEntrar, y ponerlo a cantar de nuevo. (sin necesidad de VorbisEntrar2).

Pensandolo mejor, quizás te convenga, al menos 2 vorbisEntrar, cuando uno ha finalizado, ya tienes preparado el otro para empezar a cantar la siguiente canción, y así disminuyes la pausa entre canciones,

Si estoy equivocado, ya me contarás.

[OscarG]

Ya lo siento no ser tan claro con mis preguntas y mi código:

El código en si lo hice muy rápido y es sólo para mis pruebas internas, pero tienes razón, no es escusa...
Desde q estoy en este foro, me estais dando unas lecciones de humidad y de buena programación, no soy nada .

Mi intención es tener varios sonando a la vez, no pensaba q pudiese haber algún problema ya q con otros componentes los he utilizado y iba bien.

Sería algo asi como, uno para música de fondo y otros para efectos (es para un juego), normalmente sonaría uno o 2 a la vez, pero tendría varios cargados para q suenen en el momento...

Aunq el problema q tengo, también me daría con una sola canción ya q el error sale cuando paro la música y seguidamente destruyo el objeto.
venga un saludo a todos

[[Lepe]]

Empezado por OscarG

no soy nada

Ni yo


Despues de ver los fuentes del Audio Components Suite, el bucle del contador está bien, Si acaso, metele Application.ProcessMessages y/o Aplication.HandleMessages.

Al meter esas lineas, se puede ralentizar el programa mucho, haz pruebas.

El AudioOutput debería tener otro evento distinto cuando se hace un Stop explicitamente, de cuando se termina la canción por llegar al final. Sin embargo el componente lo unifica todo en el evento OnDone, (tanto en el ACSOutput como en el TACSThread, así que no tenemos oportunidad de saber por qué se ha parado.

Lo único es que no se liberan de forma independiente, sino que ha de esperar a que todos los reproductores se paren, para despues liberarlos todos con los FreeAndNil. No sé, estamos esperando a que llegue el ultimo de la cola, para despues decirles a todos.... 'Lo siento, ya hemos cerrado, vuelvan ustedes mañana', ¿me entiendes?; quizás por eso sería conveniente usar un evento AudioOutputDone distinto para cada uno de ellos.

Inconveniente: tener una variable booleana "LiberarComponente" para saber en ese evento si debemos liberar el componenete o no. Dicha variable permanece siempre a falso, y se pone a True en el FormClose. Como ves se complica mucho para hacer lo mismo, así que : "diosito que me quede como estoy" .

saludos

[[Lepe]]

Empezado por OscarG

Aunq el problema q tengo, también me daría con una sola canción ya q el error sale cuando paro la música y seguidamente destruyo el objeto.

Por supuesto, es que DEBES esperar al evento OnDone, para despues liberarlo.

[Mick]

Solo comentar una cosa, si el componente "casca" al intentar liberarlo, es un bug del componente en particular, no vale una excusa como "claro como esta en medio de la ejecucion hay que esperar a que la cancion finalize" esto no es de recibo, si a un componente u objeto se le ordena que se destruya, es responsabilidad del propio componente realizar las acciones necesarias para destruirse correctamente, parar la cancion o hacer lo que sea para no fallar.
En resumen, yo no utilizaria una libreria que tuviese problemas o bugs de ese tipo.

Por otro lado en este caso particular, el problema puede que no venga del componente en si, sino en que el orden de destruccion de objetos del codigo realmente no parece correcto.
Esto lo digo por el objeto TAudioOut es el que accede y utiliza el objeto TVorbisIn, como podemos deducir de la siguiente asignacion durante la inicializacion:

TAudio.Input:= TVorbisEntrar;

Es decir el objeto TAudioIn guarda un puntero o referencia al objeto TVorbisIn.

De esto se deduce que lo logico seria destruir primero el objeto TAudioIn y despues su TVorbisIn correspondiente. Haciendolo al reves, el objeto TVorbisIn deja de existir antes que el objeto TAudio, y este ultimo no se tiene porque enterar de que el TVorbis ya esta destruido de modo que puede intentar acceder al objeto TVorbis "despues" de que este ya haya sido destruido dando el logico error.

Otra posible solucion si se quiere destruir los objetos en el orden inverso seria hacer un:

TAudio.Input:= nil;

Antes de destruir el objeto TVorbisIn, para que no quede en la propiedad TAudio.Input un puntero a un objeto que realmente ya no existe.

En resumen como regla general:

No se debe destruir nunca un objeto si todavia existen otros objetos que hace referencia a él. Si hacemos esto, los objetos que guardan punteros o referencias al objeto destruido pueden dar errores cuando traten de accede a un objeto que ya no existe.
Esta regla es generica, despues en casos particulares puede que no sea necesaria, por ejemplo si los objetos con los que estamos trabajando y que enlazamos tienen internamente programado algun tipo de sincronizacion o aviso de destruccion entre si para evitar el error. Pero en estos casos estaria indicado y explicado en la documentacion de los objetos o librerias que utilicemos.

No he examinado el codigo fuente ni la documentacion de los componentes que utilizas, de modo que no se si realmente esos componentes utilizan algun tipo de evento o aviso interno para evitar este tipo de errores, asi que no se si todo lo que he dicho en este post es valido para tu caso particular.

Saludos

[[Lepe]]

Los componentes trabajan con Threads, no creo que se le pueda dar la orden de destrucción y marchando que es gerundio, habrá que esperar la respuesta por parte de ese Thread.

No hay que esperar a que termine la canción, hay que esperar a que el Thread se entere que se ha procesado el Stop de la canción .

Yo tampoco he mirado a fondo los fuentes, solo he visto 3 archivos .pas de los 45 que trae, y suman 288 kb de código fuente.

Para ser unos componentes gratuitos, con codigo fuente, que permite que los modifiques y los uses en aplicaciones gratuitas como comerciales... No creo que se le pueda criticar nada.

Saludos

[Mick]

Empezado por Lepe

Los componentes trabajan con Threads, no creo que se le pueda dar la orden de destrucción y marchando que es gerundio, habrá que esperar la respuesta por parte de ese Thread.

La respuesta a que se haya finalizado el thread debe esperarla el destructor del objeto, en el momento de llamar a Free, esto debe ser totalmente transparente al programador que use la libreria.

Es decir cuando hacemos:

ObjetoQueSea.Free;

Se ejecuta el codigo del destructor del ObjetoQueSEa y esa linea de codigo no debe acabar hasta que realmente el objeto este destruido, y ahi dentro es donde el propio objeto debe hacer lo que sea, destruir threads y esperara, etc, y no salir nunca hasta que tenga una destruccion real y "limpia" del objeto y de todos los recursos y memoria que utilice.

Si las librerias que utilizamos tienen bugs o fallos de diseño de ese tipo, es cuando nuestros programas pueden empezar a realizar cosas raras y aparentemente inexplicables. Hay que tener en cuenta que en cualquier programa de alto nivel un gran porcentaje del codigo no es nuestro , sino codigo de librerias externas y ya es bastante complejo arreglar los bugs propios como para aun por encima tener que romperse las cabeza con los bugs del codigo de terceras personas.

Empezado por Lepe

Para ser unos componentes gratuitos, con codigo fuente, que permite que los modifiques y los uses en aplicaciones gratuitas como comerciales... No creo que se le pueda criticar nada.
Saludos

Obviamente cualquier software se puede criticar desde el punto de vista tecnico, porque un software sea o deje de ser libre o gratuito, no significa que sea mejor o peor y que no se le pueda criticar en ese aspecto. Cualquier software con un minimo de lineas de codigo tiene bugs y esto no hay porque ocultarlo.

Independientemente de eso, ten en cuenta que lo que dije fue de una forma general refiriendome a cualquier tipo de software que tuviese ese defecto, si lees con mas detenimiento el post, he dado mas opciones no solo la posibilidad de que esa libreria tuviese, a mi juicio, algun tipo de bug o diseño erroneo.

Saludos

[OscarG]

Sólo por comentar

poniendo TAudio.Input:= nil falla.

No le he visto mucha solución y no me queda más remedio q utilizar el componente por falta de tiempo.
Poco a poco iré indagando en él para ver si consigo arreglar el problema...por ahora lo q he hecho es meterle un contador de tiempo y si no se libera en ese tiempo, entonces, doy como error al sonido y no lo vuelvo a utilizar durante toda la aplicación...

venga, gracias por la ayuda