puertos dummy en firtro

Rsantct commented 7 years ago

@rripio

Hace tiempo pensaba en este problema de las conexiones automáticas al encenderse mplayer y mpd, y se me ocurrió (y no escribí) que deberían conectarse a unos puertos "dummy". Miré en su día cómo implementar un cliente dummy y me desanimé: no caí, y caigo ahora, que lo obvio es hacer dos entradas "sumidero" en brutefir (o eca, para el caso) que no vayan a ninguna parte. A partir de ahí todo es negocio del selector de entradas.

@amiguelez

Me parece muy buena idea esa Roberto.

+1 Es buena idea para resolver el asunto del los players que se quieren conectar en jack.

He hecho unas primeras pruebas con puertos dummy en jack directamente en lugar de en brutefir/ecasound.

bin/jack_dummy_ports.py

    #!/usr/bin/python
    # -*- coding: utf-8 -*-
    import jack
    jackdummy = jack.Client("dummy")
    jackdummy.register_port("null_0", 1)
    jackdummy.register_port("null_1", 1)
    jackdummy.activate()

Ahora basta con importarlo en bin/server_process.py import jack_dummy_ports.py

Et voilà, listos para conectarles lo que sea

┌──────────────────── [Audio Connections] ────────────────────┐
│               brutefir:fr_L -> system:playback_1            │
│               brutefir:fr_R -> system:playback_2            │
│              ecasound:out_1 -> brutefir:input-0             │
│              ecasound:out_2 -> brutefir:input-1             │
│       pulse_sink:front-left -> ecasound:in_1                │
│      pulse_sink:front-right -> ecasound:in_2                │
│           mplayer_tdt:out_0 -> dummy:null_0                 │
│           mplayer_tdt:out_1 -> dummy:null_1                 │
│                                                             │
│                                                             │

Qué os parece?

rripio commented 7 years ago

Guay.

-- Roberto Ripio

Rsantct commented 7 years ago

Lo pondré en una branch para que lo podamos probar en varios entornos, en principio parece estable y no observo consumos de cpu ni cosas raras.

La adaptación a lo de ahora creo que sería declarar en los player estos puertos como destino para que si están encendidos vayan ahí, Luego será el selector de entradas el que los enchufe a la entrada de firtro (brutefir/ecasound). ¿Os parece?

amiguelez commented 7 years ago

Me parece fenomenal.

Enviado desde algún lugar

El 29 ago 2017, a las 7:50, Rsantct notifications@github.com escribió:

Lo pondré en una branch para que lo podamos probar en varios entornos, en principio parece estable y no observo consumos de cpu ni cosas raras.

La adaptación a lo de ahora creo que sería declarar en los player estos puertos como destino para que si están encendidos vayan ahí, Luego será el selector de entradas el que los enchufe a la entrada de firtro (brutefir/ecasound). ¿Os parece?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

amiguelez commented 7 years ago

Y que pasa con shairport y demás que no tienen soporte nativo jack? Se creaba un puerto en jack nuevo si mal no recuerdo.

Enviado desde algún lugar

El 29 ago 2017, a las 7:50, Rsantct notifications@github.com escribió:

Lo pondré en una branch para que lo podamos probar en varios entornos, en principio parece estable y no observo consumos de cpu ni cosas raras.

La adaptación a lo de ahora creo que sería declarar en los player estos puertos como destino para que si están encendidos vayan ahí, Luego será el selector de entradas el que los enchufe a la entrada de firtro (brutefir/ecasound). ¿Os parece?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Rsantct commented 7 years ago

Esas fuentes hablan con alsa o pulseaudio, y así aparecen agregadas en jack. En principio no son directamenrte seleccionables, aunque en la práctica podemos definirlas en la lista de inputs sobre esos puertos de jack comunes, para que a efectos prácticos sean visibles en la lista de entradas.

Rsantct commented 7 years ago

Ya está disponible para que la probéis la brach "dummyports". Los cambios detallados en doc/dev/

Rsantct commented 7 years ago

En unas primeras pruebas, parece que todo opera bien.

A destacar que mplayer y mpd quedan predispuestos hacia los puertos dummy de jack. Se sigue verificando .mpdconf al arranque para evitar sustos.

Como curiosidad, mpd v0.21 no deja de conectarse al puerto dummy de jack aunque lo seleccionemos como fuente de jack brutefir/ecasound. Esto me parece inocuo y hasta conveniente*.

(*) edito: más que conveniente, es lógico que mpd siga conectado siempre a sus destination_port=dummy:null_x, ya que, durante su funcionamiento normal, mpd no se desengancha de motu propio de ellos. Luego es el selector de entradas el que además lo encancha a brutefir/ecasound.

Rsantct commented 7 years ago

Me temo que MPD en cada cambio de pista se desconecta de jack y al reconectarse lo hace a los puertos dummy, con lo cual se deja de oir. La opción always_on "yes" en .mpdconf no evita esto.

rripio commented 7 years ago

¿Has probado con:

 enabled         "yes"
 always_on       "yes"

?

2017-09-05 20:21 GMT+02:00 Rsantct notifications@github.com:

Me temo que MPD en cada cambio de pista se desconecta de jack y al reconectarse lo hace a los puertos dummy, con lo cual se deja de oir. La opción always_on "yes" en .mpdconf no evita esto.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AudioHumLab/FIRtro/issues/30#issuecomment-327260598, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkTEeBaRhrUHrjAFxzWCf0GRZU-9JuPks5sfZEngaJpZM4PFEHI .

-- Roberto Ripio

Rsantct commented 7 years ago

Ooops, si si lo probé así con las dos opcione, PERO me temo que ayer hice algo mal porque ahora va bien :-/ Gracias, voy a seguir probando

rripio commented 7 years ago

Uf... :-)

2017-09-06 10:24 GMT+02:00 Rsantct notifications@github.com:

Ooops, si si lo probé así con las dos opcione, PERO me temo que ayer hice algo mal porque ahora va bien :-/ Gracias, voy a seguir probando

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AudioHumLab/FIRtro/issues/30#issuecomment-327412371, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkTEezkT3TQN936bnqSxGodI0pmYXctks5sfla1gaJpZM4PFEHI .

-- Roberto Ripio

Rsantct commented 7 years ago

Parece que todo va bien, invito a comprobar con la nueva branch dummyports_rev en la que he aprovechado para limpiar y reordenar funciones, en especial una gestión poco acertada de los "players integrados" al arranque y durante los pausados opcionales. Intento resumir:

Los nuevos puertos dummy se detallan en doc/dev, usados solo en MPD, no es necesario aplicarlos en Mplayer se sigue usando noconnect
inirfirtro.py deja de verificar los players integrados
Nuevas opciones simplificadas en audio/config para pausar/reanudar los players integrados, se revisará durante la conmutación de server_input.py que se ha simplificado y ahora usa el nuevo módulo autónomo players_integrated.py
Se ha puesto write_status=False cuando se recibe la orden 'input restore' en server_process.py, ya que no es necesario e interfiere con el gestor de la radio radio_channel.py que solicita 'input restore' cuando la entrada actual es la tdt.

La branch dummyports es OBSOLETA, queda sustituida por dummyports_rev

rripio commented 7 years ago

Genial. lo pruebo ASAP (me he saltado una, pero mi cabeza ya no da...) =:' /

El 6 de septiembre de 2017, 20:29, Rsantct notifications@github.com escribió:

Parece que todo va bien, invito a comprobar con la nueva branch dummyports_rev en la que he aprovechado para limpiar y reordenar funciones, en especial una gestión poco acertada de los "players integrados" al arranque y durante los pausados opcionales. Intento resumir:

Los nuevos puertos dummy se detallan en doc/dev, usados solo en MPD, no es necesario aplicarlos en Mplayer se sigue usando noconnect

inirfirtro.py deja de verificar los players integrados

Nuevas opciones simplificadas en audio/config para pausar/reanudar los players integrados, se revisará durante la conmutación de server_input.py que se ha simplificado y ahora usa el nuevo módulo autónomo players_integrated.py

Se ha puesto write_status=False cuando se recibe la orden 'input restore' en server_process.py, ya que no es necesario e interfiere con el gestor de la radio radio_channel.py que solicita 'input restore' cuando la entrada actual es la tdt.

La branch dummyports es OBSOLETA, queda sustituida por dummyports_rev

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AudioHumLab/FIRtro/issues/30#issuecomment-327573383, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkTEXdH7VV6VbZyzhenwf69ieuKAGggks5sfuSSgaJpZM4PFEHI .

-- Roberto Ripio

Rsantct commented 7 years ago

Podemos cerrar esta issue tras haber probado en varias máquinas las nuevas configuraciones que ya están actualizadas en la branch master Si surgiera la necesidad de revisar algo, podemos abrir nueva issue al respecto.

AudioHumLab / FIRtro

puertos dummy en firtro #30