IEC 61883-6 AM824 Stream Format Bit fragen

[Marco H. (damarco)]

Kann mir jemand einen Tip geben ... im vierten octet gibt es einen 
unterschied den ich mir nicht erklären kann ? Die Formate müssen sich ja 
in irrend etwas unterscheiden ? Den Rest habe ich heraus bekommen nur 
eben die 0x40 -> 0x50 ?

Bin ich Opfer eines falschen Papers oder macht hier Apple was falsch ? 
Denn das Bit wäre im reserved Bereich.

Siehe Anhang....

[Rufus Τ. F. (rufus)]

Magst Du etwas mehr elaborieren, worum es überhaupt geht?

[Marco H. (damarco)]

Ja sicher ;).. Die Audio Daten beim AVB können in ein IEC 61883-6 Frame 
verpackt werden. Das unterstützte Format wird hier in einer 64bit 
breiten Variable kenntlich gemacht.

Apple liefert je nach Konfiguration 6 Formate zurück. Bis auf die 
Sampling Rate konnte ich keinen Unterschied ausmachen, nur das ein Bit 
im Reserved Bereich kippt. Wo nun der Unterschied sei, war meine Frage.

Ich werde mal das Format wechseln und mit Wireshark schauen ob man im 
Frame Header was erkennt.

Die Antwort werde ich auch nicht in der  300€ teuren IEC 61883-6 finden.

Ich habe das in mein Json mal besser aufgelöst... Ist kein Apple mehr, 
das Gerät kann nur ein Format...

[Rufus Τ. F. (rufus)]

Marco H. schrieb:
> Die Audio Daten beim AVB können in ein IEC 61883-6 Frame verpackt
> werden.

Meinst Du ernsthaft, daß jetzt allen anderen klar wird, was Du da machen 
willst?

Ich kann nur vermuten, daß es um Audioübertragung im Netzwerk gehen 
könnte -- Apple setzt dazu AirPlay (früher "AirTunes" genannt) ein, aber 
das ist eigentlich im Rahmen von "shairport" schon recht lange bekannt.

[Clemens L. (c_l)]

Marco H. schrieb:
> Die Antwort werde ich auch nicht in der 300€ teuren IEC 61883-6 finden.

FireWire statt AVB:
http://1394ta.org/wp-content/uploads/2015/07/2009013.pdf

[Marco H. (damarco)]

Danke, so etwas ähnliches habe ich schon gefunden. Leider finde ich 
keine Antwort was das Bit zu bedeuten hat. Es half mir die anderen 
möglichen Sampling Frequenzen zuordnen zu können.

Es macht im Stream keinen Unterschied, das dass setzen des Formates 
erfolgreich war erkennt man an den mehr Samples im Frame. Auch andere 
AVB Controller zeigen im Stream Descriptor keinen unterschied an.

Ich werde das erst mal vermerken, ewt. komm ich später darauf ;)

@rufus sei mir nicht sauer, um das zu erklären könnte man Bücher 
schreiben ;)

Der MAC kann noch mehr 
https://en.wikipedia.org/wiki/Audio_Video_Bridging

Ich hatte einfach die Hoffnung das jemand mit ließt der sich mit 
ähnlichen Dingen beschäftigt..

Also das soll ein AVB Controller werden, mit diesem lassen sich die 
Geräte steuern bzw. konfigurieren. Controller die kein Geld kosten und 
zudem auch noch funktionieren sind Mangelware. Das Projekt kann mehr, da 
es mit REST/API und Json arbeitet ergeben sich viele Möglichkeiten. Auch 
Geräte per IOT einzubinden, Fernwartung (geht sonst nicht -> Layer2)...

Der Controller läuft als Daemon und wird über lighttpd + fastCGI Modul 
angesprochenen. Das Modul erzeugt auch die Json response. Durch das 
Prinzip  muss man von AVB keine Ahnung haben und kann den Controller 
nutzen, einfach die API lesen ;)


Als Plattform könnte ein RPI oder ähnliches dienen, ursprünglich war es 
angedacht es auf einer AVB Switch laufen zu lassen.

Hilfe könnte ich gebrauchen, z.bsp Javascript und HTML5 :)

[Marco H. (damarco)]

so gelöst...

die Formate unter scheiden sich im async und synchron Mode.

Synchron heißt das alle 125µs ein Frame mit 6 Samples 48KHZ oder 12 
Samples 96KHZ versendet werden.

Asynchron das gelegentlich weniger oder mehr Samples gesendet werden.

Das hängt damit zusammen ob der Teil der die Pakete packt synchron oder 
asynchron mit der Sample Frequenz läuft.

Hat ein Sender mehrere Taktquellen bleibt ja nur der asynchron Mode 
übrig.

Ich werde das mit Wireshark noch mal prüfen....

[Marco H. (damarco)]

Hmm also einen Unterschied sieht man nicht in den Frames. Aus andere 
Quelle scheint aber meine Vermutung richtig zu sein ;). Ich gebe mich 
damit erst mal zufrieden... Anbei das Json...