Unmöglich.. Das TALKSAFE ist zwar nett gedacht aber beim Einsatz bei einer Behörde sollte man gleich mehrere Kaufen.

Mag zwar für den Empfang in Firmen mit zufriedenen Kunden geeignet sein, für alles andere und in Anbetracht der Gereiztheit seiner Kunden untauglich.

Noch was mit dem man die 100€ aus den Kopf schlagen kann.. Je nach dem wo man das Einsetzt kommt auch der Datenschutz eine Rolle. Damit nicht alle im Raum das Anliegen mitbekommen, müssen die Anlagen eben nur so laut wie möglich und sehr verständlich sein. Mein Tipp biete was vernünftiges an was nicht völlig aus den Rahmen kippt. Dafür überzeugst du mit einem Funktionierenden System und passenden Konzept.

Solche Kameras können auch PTP Fähigkeiten besitzen...

Die Errors die du im Controller siehst kommen von den Geräten und diese kann man auch so werten. Gleichwohl man die Ursache auf den ersten Blick nicht deuten kann.

Dein Gerät steht ohne Clock da... Wie kommen andere PTP Pakete ins Netzwerk.. meist über ungewollte Brücken. Die durch falsche VLAN Einstellungen passieren oder Hardware die als Ring verschaltet wurde.

IGMP die Ursache wäre kommt es zu einen Timeout und die Switch gibt die Multicast Pakete nicht mehr auf den Port aus. Der Client registriert sich erneut und die Sache fließt wieder.

Der Log deutet auf multiple Clock Sources hin , die Hardware weiß dann nicht welchen soll ich jetzt nehmen.. Kann es sein das noch ein anderes Gerät PTP Pakete ins Netzwerk bringt ? Dann musst du die Netzwerke Hard mit einen VLAN trennen. PTPv1 und PTPv2 z.Bsp...

Ich will das Produkt https://www.neutrik.com/de/produkte/au…n-oem-solutions nochmal auseinander nehmen.

Es kann nur 100MBit/s links -> veraltet und es basiert auf einen Marvell ARM Switch Baustein. Der ARM der da oben ist für die Peripherie . Von Marvell bin ich geheilt und in der Praxis die Kunden sicherlich auch.

Die Idee war ewt. einen RPI CM4 hierzu zu ertüchtigen. Wenn man die Software schon mal entwickelt hat, diese auf andere Industrie fähige Hardware zu portieren. Soweit die Idee, die Praxis ist dank NDA sehr weit entfernt. Nun bin ich am prüfen ob NXP die bessere Wahl wäre... Der günstige Preis eines RPI CM4 erschien mir als nicht so sehr Risikoreich.

Hallo,

1. Ich beschäftige mich seit 2014 mit TSN und mit dem Controller wurde ernsthaft vor 2 1/2 Jahren begonnen.
2. PTP ist nicht alles was man für ein TSN fähiges Gerät benötigt. Du beklagst den nicht kostenfreien IEEE Standard. Alles bei Broadcom steht unter NDA nicht einmal ein Datenblatt bekommt man. Extrem schlechte Voraussetzungen für die Entwicklung eines Treibers. Mit der i210 musst du dich ja auskennen, das kann der Treiber von der Broadcom PHY nicht einmal ansatzweise.

3. Man braucht kein Wine ,Win10 hat ein Linux Subsystem. Außerdem ist das Projekt vom Ansatz her auch auf anderen OS lauffähig. Deswegen ja auch der wechsel zu cmake Im Übrigen Hive lässt sich auch für Linux übersetzen. Wenn du einen Controller mit Benutzeroberfläche suchst.

4. Der RME Controller ist lustig, weißt du wie dieser funktioniert ? Ohne PC gar nicht, denn dieser läuft auf dem Rechner wo der Treiber läuft.

5. Kenne ich aber bisher noch keine Hardware gesehen, auch keine Entwicklungsumgebung.

Nunja es ist eben alles nicht so einfach und ich mit der Meinung das dass Projekt noch nicht so weit ist um es zu veröffentlichen.

Momentan arbeite ich an einer neuen Flow API. Das Projekt hat auch ein völlig anderen Ansatz und des wird auch so bleiben. Wenn sich keiner findet und mit HTML5 eine Oberfläche baut.

Ja aber... Hardwaremäßig sind die Ports alle auf einer Switch (Marvell) geführt. Einziges Problem ist das du die Karte auch so einstellen muss, als Brücke....

Sonst siehst du zwar den Bose Amp aber nicht die Teilnehmer am Master Port. Du willst ja einen Stream zwischen den Ports aufmachen.

Das Problem sind die Spitzen und die haben es in sich. Probleme mit der Spannungsversorgung sind die häufigsten Ursachen wenn das Ding abschmiert. Der Rest am Code der IDE und des Users.

Ein weiteres Problem besteht darin das im dem Ding das ganze Wlan Zeug per Software auf einem Core läuft. In den heute üblichen 2.4GHZ Umgebungen muss die winzige CPU alles verarbeiten um feststellen "war nichts für mich" . Die folge ist das dass Ding regelmäßig bei hoher Trafic auf den Bändern aussetzt oder sogar ganz abschmiert. Ich hatte die Dinger damals auch für den IOT Kram mit eigenen MQTT Stack. was das Ding können soll und dann wirklich machte war grausam. Zumal sich dann herausstellte das dass Problem in der Hardware liegt.. Mit dem ATWINC1500 lief es dann bis heute ohne ärger durch. Amazon wusste schon warum er einen großen Bogen um das Zeug machte.

Dein Problem ist er das du zu jeder Lampe eine TCP/IP aufbaust zu dem Controller. Besser wäre es das nur einer das macht und dann es zu den Lampen z.Bsp auf den 800MHZ Band Module weiterleitet. Der TCP/IP Kram braucht viel Speicher und Strom...

Das Problem ist er der ESP32 der braucht Minimum 700mA.

Zumal wie beim Switch die Anzahl der TCP/IP Verbindungen begrenzt ist. Ein ESP32 ist einfach die falsche Hardware wenn es um Stromverbrauch geht. Andere Boards brauchen da deutlich weniger....

Also gut es bringt nur was wenn du viele Linien hast und dort unterschiedliches Programmmaterial abspielen musst. Z.Bsp jeder Laden hat sein eigenes Radio, Zonen etc.

Früher hat man das über eine Schaltmatrix gelöst. In der ELA Zentrale war eine Relais Matrix und diese wurde von einer Zentraleinheit gesteuert. Mit Pilotton 20Khz, so das sogar der Ausfall registriert wurde und auf einen Ersatzverstärker geschaltet wurde.

Heute kann man das per Dante und co. Raumsparender Lösen aus 3 Schaltschränken wird einer. Das jeder Lautsprecher auch ein Netzwerkteilnehmer ist kannst du dir aus den Kopf schlagen. Da der Aufwand der Infrastruktur der Wahnsinn ist. Deswegen gibt es auch nur wenige Aktiv ELA Lautsprecher, keiner projektiert so etwas in großen zahlen. Die 100V Technik hat sich bis heute bewährt, und man kann sogar die Lautstärke passiv beeinflussen. Funktioniert selbst nach einem Atomschlag noch zuverlässig.

Hier mal ein Beispiel https://www.monacor.de/produkte/besch…dante/it-400dt/ 20W versorgt über PoE. Jetzt rechne mal aus wie viel Eingangsleistung man benötigt um die 20W an den Lautsprecher zu bringen ? Was kostet mich so ein PoE Injektor oder Switch und kann die auch die 20W Pro Port zur Verfügung stellen. Mit 40m Leitung zwischen... Die Verluste sind bei 100V er gering.

Nu du hättest mal auf der deutschen Seite schauen müssen https://www.monacor.de/produkte/beschallungstechnik/

Zitat

Bei uns arbeiten Tüftler, Großprojekt-Planer, Berater, Akustiker und Ingenieure. Und alle haben eines gemeinsam: Auch wenn Audio over IP vieles ermöglicht, ist die stabile, kosteneffiziente 100-Volt-Technik noch immer in vielen Projekte die optimale Lösung. Wir haben unzählige Projekte mit dieser Technologie umgesetzt und freuen uns auf viele weitere.

Hust...

Du vergisst aber auch wenn kein Wlan zum Einsatz kommt das die Ethernet Infrastruktur wenn jeder LS einen Port hat ein enormer Aufwand darstellt. Mit 100 Switches zwischen wird der PTP Clock nicht schöner der da nur durch gereicht wird. Dante Geräte mit Daisy Chain sind sehr selten und da kann man auch nicht all zu viel hintereinander schalten. Auch 200 Wlan Clients mit Syncronsierten Geräten Stelle ich mir mit einem Standard AP Point schwer vor. Alleine die Broadcast macht das Band zu....

Im Endeffekt muss du doch wieder LS Gruppen bilden und nur die Verstärker haben dann Dante. Ich erkenne jetzt nicht wo die Innovation ist. Richtig Projektiert geht eine 100V Anlage kaum kaputt und die Übertrager, Verstärker sind vom fGang her HIFI tauglich. Nach Klo klingt da kaum noch etwas.

Alternativ aktiv Lautsprecher, allerdings bezahlt man den Amp jedes LS mit. Im Dauerbetrieb sind die auch aufgrund das Netzteils und es muss schon billig sein bald defekt. 2000 LS dann zu reparieren macht keiner, ein passiver LS geht in der Regel nicht kaputt.

Zitat von chris216

Kerkos altern auch nicht so wie Elkos - drin lassen. Das dürfte in der Tat passen. (Ganz schön weit weg von den ICs, die Kerkos. Das geht auch schöner...)

Nunja es gibt Biegerisse oder auch schon mal Kurzschlüsse. So ganz unschuldig sind die Kondenstoren nicht.

Leider nein, Dante steuert nur den Stream. Wenn du die Teilnehmer überwachen und steuern willst bis t du auf die Hersteller der Geräte angewiesen.

Fakt ist auch eins, das Dante etc. für die meisten Lösungen viel zu Aufwändig und teuer sind. Die 100V Technik ist unschlagbar günstig und gut geplant braucht man die Flexibilität meist nicht.

Das lohnt sich nur für wirklich große Installationen, wo es auch darum geht einzelne Gerät zu überwachen. Du brauchst ja nicht nur Netzwerk sondern auch eine Spannungsversorgung am Lautsprecher. Die PoE Lösungen sind in der Leistung stark begrenzt, vor allem und für weite Strecken nicht geeignet -> Spannungsabfall.

Wlan ist in den Innenstädten im 2,4GHZ Band kaum noch benutzbar, für einen sicheren Stream auch noch mit wenig Latenz er schwierig. Da ist ständig Ärger zu erwarten...

Mal was anderes außerhalb dem Controller Thema..

Mir wurde im Dezember ein Raspberry Pi CM4 https://www.raspberrypi.org/products/compu…ry-pi-cm4001000 mit dem IO Board https://www.raspberrypi.org/products/compu…ule-4-io-board/ auf den Tisch gelegt.

Nebst der unsauberen Verarbeitung wird das Board als "Onboard Gigabit Ethernet PHY supporting IEEE1588" beworben.

Ich habe mir das auch schon denken können und mich schon kurz im Dezember mit beschäftigt. Das geladene Standard Modul für die Broadcom PHY keine Hardware Timestamps, das haben jetzt auch andere mitbekommen und kotzen bei GIT darüber aus https://github.com/raspberrypi/linux/issues/4151 . Das Problem alles bei Broadcom steht unter NDA selbst die Datenblätter. Ein super Grundlage um Treiber zu entwickeln und ich glaube ich nicht das dies die Raspberry Pi Foundation machen wird. Obwohl das eine wichtige Voraussetzung wäre um wie beworben das Modul in der Industrie zu verwenden. Macht keiner Bastelkram bleibt Bastelkram..

Aber das IO Board hat auch einen PCIe Slot, also hat der Marco eine Intel i210 aufgesteckt einen PTP fähigen Kernel gebaut und mit dem linux PTP Projekt versuche gemacht.

Um festzustellen das zwar die PHY synchronisiert und es auch gelingt diese Uhr mit dem System zu synchronisieren. Naja fast, denn der Clock vom dem Board ist derart miserabel das dieser stark weg läuft und es mit der Regelschleife im Userspace dann nicht mehr gelingt das die PLL einrastet.

So ein paar Stunden läuft es dann ist auf einmal Feierabend, warum auch immer. Schaut man sich die Linux AVB Projekte so an ist nichts dabei was wirklich verwendbar ist. SRP,QOS werden von der Konsole aus gesteuert und einen einen IEEE1722.1 Controller gibt es erst recht nicht. Man startet Talker und Listener auch per Hand und hofft das was ankommt. Fazit von 2013 bis heute ist man nicht sehr weit gekommen...

Also ich möchte ein paar Dinge Posten. Der Controller kann wenn man es es aktiviert sich als eigenes Entity im AVB publizieren. Das ist schon seit einen Jahr vorhanden, aber nur mit dem Deskriptor "Entity" -> Konfiguration 0. Jetzt ist das Entity vervollständigt worden. In Vorbereitung für die versprochene Überraschung. Es wird so sein das man Deskriptoren in ein einem Konfigurationsfile beschreiben kann und das der Entity Core die Entsprechenden Funktionen bereitstellt -> ist aber noch Baustelle..

Die Verfahrensweise der Control Values wurde überarbeitet. Die Values werden Count,Type,Range werden aus den Daten des Deskriptor geprüft. Man kann dem Entity keine falschen Values übergeben, oder unvollständige. Wie schon seit über 1 Jahren kann der Controller mit allen Typen umgehen. Die weise wie sie im Json dargestellt werden wurde verbessert. Lässt sich einfacher mit Javascript lesen.. Später kann man das Json Objekt einfach per POST senden und somit die Values setzen.

Es funktioniert natürlich auch mit dem Deskriptoren Mixer,Matrix ! Siehe Bild, da sieht man schon das besser Json Format. Mixer muss man erst mal verstehen . Es beschreibt eine Möglichkeit Control values in einer Quelle zu Mischen. Deswegen werden nur Linear Values unterstützt. Das Thema Sources ist ziemlich wirr und ich werde das noch besser da stellen müssen. Sources lassen sich ja schon per HAL verfolgen.

Das geht schon mit etwas Logik zwischen... In dem man den Break erkennt und dann die Quelle umschaltet. Im richtigen Moment... bis 1sec... Pause im Frame ist ja kein Problem. RDM sollte da aber nicht oben sein...

Das eigentliche Umschalten muss vor dem Treiber erfolgen.... Das lässt sich mit Logik realisieren geht aber mit einem AVR der zwei Serielle Schnittellen hat einfacher. Hat aber den Nachteil das das Schieben von Ein zum Ausgang ein Byte + Jitter Versatz im Frame ausmacht. Mit einem FPGA ist das überhaupt kein Problem

https://store.arduino.cc/arduino-mkr-vidor-4000 oder was anderes FPGA Board...

Es gibt noch andere Aspekte zur Monokompatibilität. Im Rundfunk wird R+L Zusammen Summiert -> Mono. Wenn du dein Mix auf eine Platte pressen möchtest muss der Mix auch gewisse Anforderungen erfüllen.

Fazit: Ein guter Mix Erfüllt die Anforderungen im Rundfunk und lässt sich auch auf Platte Pressen. Alles andere ist ein schlechter Mix. Bisher haben das die Künstler die Millionen mit ihrer Musik verdient haben ganz gut gekonnt.

Es gab aber durchaus schon Fehlleistungen, die auf großen Ablagen irgendwie komisch klangen. Solche Geschichten wie <200Hz Phasenunterschiede etc...

Wie versprochen wollte ich euch nicht mit jeder Neuigkeit langweilen, also war hier erst mal eine weil pause.

Der Code hat eine bessere Struktur bekommen und wurde so umgearbeitet das er auf verschiedenen Plattformen lauffähig wäre. Es gab starke Veränderungen Im Code , die ich jetzt nicht im einzelnen abspulen möchte. Jedenfalls ist er wieder ein Stück fixer geworden .

An der API gab es Änderungen was die Json Antworten angeht, Values mit vielen Werten werden jetzt besser angezeigt, siehe unten. Das Betrifft auch die Control Values... Momentan arbeite ich am einheitlichen Errorhandler, hierzu muss man ab und zu den Code nochmal anfassen. Da ergeben sich dann meist auch Optimierungen. Unter Linux bin ich mit dem BpF vom Kernel jetzt grün und es gibt vermutlich April, Mai noch eine Überraschung.... So läuft das Projekt stabil..

{
  "status": "SUCCESS",
  "descriptorType": "STREAM_PORT_INPUT",
  "descriptorIndex": 0,
  "mapIndex": 0,
  "numberMaps": 1,
  "numberMappings": 8,
  "streamIdx": [
    0,
    0,
    0,
    0,
    0,
    0,
    0,
    0
  ],
  "streamCh": [
    0,
    1,
    2,
    3,
    4,
    5,
    6,
    7
  ],
  "clusterOff": [
    0,
    0,
    0,
    0,
    0,
    0,
    0,
    0
  ],
  "clusterCh": [
    0,
    1,
    2,
    3,
    4,
    5,
    6,
    7
  ],
  "_warnings": [],
  "_links": {
    "profile": {
      "href": "/avb/v1.0/profile/descriptors/controls/audioMap/"
    }
  }
}

LDAC APTX HD macht 96khz bei 24bit.. Technisch also kein Hindernis.
Auch der AES67 Support funktioniert nur mit 48khz.