Powermanager Einschaltverzögerung bei Squeezelite

[Stoni]

Hallo.

Bin grad dabei von meinem PiCorePlayer PI auf den MS4H umzustellen.

Bisher läuft die Klingel über Homeasistant, welcher direkt die Zone (auf squeezelite instanz) anspricht und den Klingelton sendet.

Leider funktioniert hier die Einschaltverzögerung des Powermanagers nicht und der Klingelton wird nur halb gespielt.

Beim PiCorePlayer hatte die squeezelite Instanz den Parameter `-S /opt/power.sh` worüber dann der Verstärker mit Verzögerung aktiviert wurde, dieser Parameter existiert in der MS4H Instanz aber nicht.

Hab Ich evtl. was übersehen, ist das nicht geplant oder ein Bug?


mfg, Thorsten

[hismastersvoice]

Bisher läuft die Klingel über Homeasistant, welcher direkt die Zone (auf squeezelite instanz) anspricht und den Klingelton sendet.

Was auch immer das heißen soll...??

Bei MS4H werden Events über URL oder Loxone-Baustein gesteuert, wenn du selber etwas direkt ansteuerst das außerhalb der MS4H Anleitung liegt, dann musst du auch den Rest von Hand machen.


Der PowerManger verzögert nicht das einschalten des Verstärker, er verzögert das Abspielen des Klingelton/TTS etc. bis er wirklich aktiv ist.
Die meisten Ams brauchen 1-2 Sekunden bis sie Ton wiedergeben, damit die Audio-Datei nicht abgeschnitten wird wird das Abspielen kurz verzögert.

Was sollte es bringen beim Klingen das Einschalten des Amps zu verzögern?

Der PowerManager ist voll integriert in das System und überwacht alle Player und vor allem die Events.
Wenn du also etwas direkt ansteuerst, dann kann es gut sein das er nicht wie geplant funktioniert.

Die Option -S brauche ich nicht, der PM ist hier deutlich tiefer reichendes Tool das nicht nur einen simple Player steuert, sondern ganze Gruppen und Event-Player etc.
Vor allem ist es kein Bug.

Handbuch

https://music-server.net/help/Powermanager1.html

[Stoni]

Hallo HisMastersVoice.

Danke für die schnelle Antwort.

> Bisher läuft die Klingel über Homeasistant, welcher direkt die Zone (auf squeezelite instanz) anspricht und den Klingelton sendet.
Was auch immer das heißen soll...??

Sorry - Das bedeutet das Ich eine Audiodatei direkt an die über Squeeze/LMS freigegebene Zone sende. Quasi ein externer squeezeplayer der MS4H nur als Ausgabe gerät verwendet.

Bei MS4H werden Events über URL oder Loxone-Baustein gesteuert, wenn du selber etwas direkt ansteuerst das außerhalb der MS4H Anleitung liegt, dann musst du auch den Rest von Hand machen.

Aber das streamen von Audio direkt an den squeezelite ist doch nichts "außerhalb der Anleitung"? Das gleiche ist beim abspielen im LMS und über Shairport dasselbe.

Hab den Wert mal absurd hoch auf 20sek gestellt, aber der Stream etc. läuft sofort, die Musik kommt nach ~2sek (wirkliche Verstärkereinschaltdifferenz) und die 20 sek bewirken zumindest im squeeze/LMS kontext bei mir nichts:

Der PowerManger verzögert nicht das einschalten des Verstärker, er verzögert das Abspielen des Klingelton/TTS etc. bis er wirklich aktiv ist.
Die meisten Ams brauchen 1-2 Sekunden bis sie Ton wiedergeben, damit die Audio-Datei nicht abgeschnitten wird wird das Abspielen kurz verzögert.

Was sollte es bringen beim Klingen das Einschalten des Amps zu verzögern?

Logisch so rum, hab Ich falsch beschrieben.

Der PowerManager ist voll integriert in das System und überwacht alle Player und vor allem die Events.
Wenn du also etwas direkt ansteuerst, dann kann es gut sein das er nicht wie geplant funktioniert.

Die Option -S brauche ich nicht, der PM ist hier deutlich tiefer reichendes Tool das nicht nur einen simple Player steuert, sondern ganze Gruppen und Event-Player etc.
Vor allem ist es kein Bug.

So wie du es beschreibst müsste er doch dann auch LMS/Squeeze/Shairpoint berücksichtigen, oder?


Die Events im MS4H zum klingeln/alarm hab Ich gesehen und funktioniere auch. Allerdings wäre es für meine Integration einfacher die Verwaltung (Welcher Sound, welche Lautstärke in welcher Zone) in meinem SmartHome system (Homeassitant) zu belassen als die Datei in MS4H hochzuladen und die Parameter für den HTTP Request anzupassen.


mfg, Thorsten

[hismastersvoice]

OK jetzt verstehe ich was du macht.

Die Verzögerung wird nur über die EventPlayer bereitgestellt, nicht generell.
Wenn du also ein Audio-Datei direkt startest spielt er sofort wie zB bei einem Radio-Stream etc.

Wenn du es nicht einrichten willst wie beschrieben musst du damit leben.

[Labmaster]

...
Die Verzögerung wird nur über die EventPlayer bereitgestellt, nicht generell.
...

Das ist auch gut so und bleibt hoffentlich auch so.

[Stoni]

Wollte grad einfach probieren den -S Parameter für squeezelite zu ergänzen, aber leider ist die Version in MS4H nicht mit den entsprechenden Flags kompiliert. Wäre ja sonst ein leichtes das bei den Alsa Parameter der Zone hinzuzufügen.

Aber warum so ablehnend?
Ist doch keine speziellen Nutzung die Ich hier mache, das "Problem" hat ja im Prinzip jeder der einen Stream startet, auch wenn Ich verstehe das das in den meisten Fällen zu vernachlässigen ist wenn hier die ersten 2-3sek fehlen.

Falls du es doch einbinden magst, oder für andere die das hilfreich finden, Ich habs jetzt mal bei mir so eingebunden.
* squeezelite mit `make all OPTS="-DGPIO"` kompiliert (manuell, oder in mstools:590, das muss aber leider bei jedem Update angepasst werden)
* `-S /usr/local/bin/power.sh` in den alsa options der zone ergänzt
* /usr/local/bin/power.sh erstellt:

#!/bin/sh

# squeezelite -S /powerscript.sh
case $1 in
    1)
        php /opt/music_server/sc.d/pm start
        sleep 2 # wait 2 sec till the amp is powered on
        ;;
    0)
         php /opt/music_server/sc.d/pm stop
        ;;
esac​

Leider muss das sleep hier noch mit rein, da pm nicht wartet und mir nicht ersichtlich war wo hier das warten stattfinden sollte.

[Labmaster]

Wenn ein normaler Stream gestartet wird (Taster an der Wand oder PM oder ...) dann möchte man ja genau das Gegenteil, nämlich das der Stream so schnell wie möglich startet und da es hier üblicherweise um Musik geht (ist ja kein Event oder Durchsage, dafür gibt es die ja extra) sind mir die ersten 2s völlig egal ob da eventuell was abgeschnitten wird (wird es im übrigen bei mir merklich nicht, würde man ansonsten eventuell bei Podcasts o.ä. merken) . Dem WAF zuliebe sollte da einfach nur möglichst schnell eine Reaktion mit Musik kommen. Ich war da im System schon auf der Suche nach 100ms Verbesserungen.

[hismastersvoice]

Stoni

Das was du machst ist einfach ein "dummes" warten, mehr nicht.

Der PM und das Event machen folgendes.
Wenn ein Event ausgelöst wird, dann kommuniziert das Event und schaut ob alle nötigen Amps an sind, wenn nicht wird gewartet, wenn die benötigten Amps schon an sind, dann wird auch nicht gewartet und die Soundausgabe sofort gestartet. Warum soll man jedes mal warten wenn man den Player startet?
Das ist insbesondere so wenn man zB Multi-Kanal-Amps nutzt wie die KAB9. Ich warte nicht 2 Sekunden auf das Klingeln wenn es nicht nötig ist wenn die Amps schon an sind.
Das Event über URL braucht bei einer Klingel weniger als eine Sekunde um auszulösen. Insbesondere die KAB9 spielt sehr schnell nach dem man das Standyby-Signal löst.

Aber warum so ablehnend?
Ist doch keine speziellen Nutzung die Ich hier mache, das "Problem" hat ja im Prinzip jeder der einen Stream startet, auch wenn Ich verstehe das das in den meisten Fällen zu vernachlässigen ist wenn hier die ersten 2-3sek fehlen.

So ablehnend... Weil das was du da machst, ist absolut sinnbefreit, das jeder Stream warten soll ob es nötig ist oder nicht.


Wenn du meinest selber an dem System rumbasteln zu müssen, dann mach das, aber ich werde sicher keine "dummen" Wartezeiten einzubauen die bereits deutlich besser gelöst sind.


Labmaster

Das ist auch gut so und bleibt hoffentlich auch so.

Keine Sorge, das bleibt ganz sicher so.

[Stoni]

Labmaster Das wäre ja weiterhin gegeben, denn statt dem sleep muss natürlich die MS4H logik an diese Stelle

hismastersvoice
Puuh.. irgendwie hab Ich das Gefühl das du mich bewußt mißverstehen willst und dich irgendwie dagegeb streubst das System in diesem Punkt besser zu machen.

Das diese Lösung mit dem sleep so quatsch ist, vor allem für ein System was häufiger genutzt wird und die Wahrscheinlichkeit das die Endstufe läuft gegeben ist, ist klar.
Deswegen hab Ich ja geschrieben:

Leider muss das sleep hier noch mit rein, da pm nicht wartet und mir nicht ersichtlich war wo hier das warten stattfinden sollte.

Meine damit dein pm script was ja die Endstufen an/aus macht, aber anscheinend nicht die Wartelogik enthält

D.h. hier müsst statt dem sleep einfach die Logik von System rein die prüft und nur wartet falls die Endstufe aus ist, und man hätte 0s unnötige Verzögerung an JEDER Stelle (events UND stream) und zusätzlich auch nirgends etwas abgeschnitten.


Sorry - bin selbst Entwickler und die OpenSource Welt gewohnt wo gemeinsam versucht die Sachen noch besser zu machen, Hilfe und Feedback willkommen ist und jeder was dazu beiträgt Funktionen zu erweitern und Bugs zu fixen. Das das hier nicht gewünscht scheint hab Ich jetzt verstanden und werd mit dem Leben was geht oder was anders suchen oder selbst machen, Schade.

[hismastersvoice]

Stoni

Das was du schreibst mag richtig sein wenn man nur mal eine Zone oder auch nur interne Zonen mit einem Event bespielen will.
Was der MS4H aber kann ist interne Zonen absolut synchron und externe Zonen nahezu synchron (weinige Millisekunden) zusammen mit der selben Ausgabe abzuspielen.
Dazu muss ein exaktes Timing stattfinden, und das geht eben nur wenn die Wartezeit nicht vom PM sondern vom Event getimt wird.

Der MS4H kann in dieser Hinsicht deutlich mehr als du denkst, und ist auch deutlich ausgeklügelter als mal ein Audio-File abspielen.
Du denkst es ist einfach mal die Logik in den PM setzen und gut, und das obwohl du das System und die Logik dahinter nicht kennst.
Wenn das Sinn machen würde, dann hätte ich das gemacht.


Feedback ist immer willkommen und ich habe schon hunderte Dinge umgesetzt die von Usern angebracht wurden, deswegen kann der MS4H was er kann.
Und ich glaube nicht das ich als Mitglied das hier eines der höchsten Renommees besitzt mir anhören muss das ich nicht bereit bin etwas umzusetzen.
Ich habe hier schon so vielen Usern geholfen, und nicht nur beim MS4H sondern auch mit Plugins für den Loxberry und anderen Dingen.
Also sei bitte vorsichtig mit solchen Aussagen.


Wenn dem so ist das der MS4H für deine Zwecke nicht passt, dann kann ich das in diesem Fall nicht ändern.
Du hättest die Möglichkeit das ganze so zu nutzen wie es vorgesehen ist und es geht, das willst du aber anscheinend eben nicht.

Ich werde aber nichts an den Events verändern das sie schlechter macht,
insbesondere beim Thema Timing für das ich einige Abende gebraucht habe das es so schnell und synchron funktioniert.


PS:
Mir ist neu das der MS4H Open Source ist...
Vielleicht magst mal im WebUI->Hilfe->Über schauen.
Zumindest für den Teil den ich geschrieben habe ist das nicht so.

[Labmaster]

Labmaster Das wäre ja weiterhin gegeben, denn statt dem sleep muss natürlich die MS4H logik an diese Stelle
....

Ich denke ich hab immer noch nicht verstanden wie das funktionieren soll.

Wie und wann soll denn die Ausgabe künstliche verzögert werden ?
Woher soll denn der MS4H wissen wann er einen Squeezestart verzögern soll oder nicht ?
Im Moment weiß er es und verzögert dann, wenn es eben ein von ihm "erzeugter" Stream ist (Event).


Wenn der MS4H "ganz normal" betrieben wird, soll eben auf keinen Fall etwas verzögert werden. (ausser bei seinen Events, wo er sich eben selbst darum kümmert)
Wie willst du dem MS4H von extern mitteilen, dass er verzögern soll ?

[hismastersvoice]

Ich habe schon verstanden was er meint.
Er will einfach die Wartezeit vom Event in den PowerManger verschieben.
So würde bei jedem Power up geprüft ob die Amp schon an ist und ggf. gewartet um die Amp einzuschalten.

Was Stoni nicht beachtet ist ganz einfach das ein Event nicht wie von ihm angedacht immer nur eine Zone betrifft. Vor allem wenn externe Zonen hinzu kommen ist es nicht mehr so einfach mit dem Timings. Man könnte einfach alle nötigen Zonen synchronisieren das ist mir aber langsam.

Er will einfach nicht die Events des MS4H nutzen sondern eigene Files von extern zu streamen.

Was in den Fall passiert ist, das die Zone sofort anfängt wiederzugeben und ein kleines Stück seines Events abgeschnitten wird

Jetzt hätte er eben gerne das immer mit dem abspielen gewartet wird.
Was aber dazu führt das ein Internet-Stream erst aufgebaut wird wenn die Amp nach der Wartezeit an ist, und somit immer länger braucht bis er wirklich spielt. Bei internen Files die nur wenige Millisekunden brauchen spielt das nur weniger eine Rolle bei Internet-Streams schon.