Pyra Docking Station..was wären euere Wünsche?


hm dann ist es eine Abwägung wie viele Nutzer VGA gerne hätten und wie aufwendig eine Umsetzung ist.
Bei Beamern ist VGA immer vorhanden. HDMI würde zb bei uralt UNI Beamern oder alten fest installierten Geräten nicht angeboten. Da fällt dann ein VGA Kabel aus der Wand.

Je nach Bedarf könnte man auch noch Displayport / DVI einwerfen.
 
Willhelm said:
Je nach Bedarf könnte man auch noch Displayport / DVI einwerfen.
DVI ist in der digitalen Single Link Variante identisch zu HDMI 1.2 ohne den ganzen Zusatzkrams. Beide nutzen TMDS zur Signalübertragung, HDMI spezifiziert lediglich in den neueren Standards eine höhere Transferrate, DVI's Ansatz dafür die Leitungen zu verdoppeln konnte sich bei HDMI nicht durchsetzen.

Der SoC liefert bereits TMDS über die HDMI Buchse, etwas anderes kriegt man auch nicht. VGA gibt's nur über einen Brückenchip, DisplayPort macht hier schlichtweg gar keinen Sinn - eine Konvertierung in diese Richtung wäre auch sehr kompliziert und mit recht großen Latenzen verbunden.

Bei den USB "Adaptern" handelt es sich um vollwertige Grafikkarten, sie erweitern nicht einfach die verfügbaren Schnittstellen sondern sind allen Einschränkungen die mit dem Handhaben von mehreren Grafikkarten verbunden sind unterworfen - der SGX Treiber ist weder für so etwas gut geeignet, noch gibt es für diese USB Chips überhaupt eine nennenswerte Linux Unterstützung abseits der alten USB 2.0 DisplayLink Teile.
 
Letalis Sonus said:
Willhelm said:
Je nach Bedarf könnte man auch noch Displayport / DVI einwerfen.
DVI ist in der digitalen Single Link Variante identisch zu HDMI 1.2 ohne den ganzen Zusatzkrams. Beide nutzen TMDS zur Signalübertragung, HDMI spezifiziert lediglich in den neueren Standards eine höhere Transferrate, DVI's Ansatz dafür die Leitungen zu verdoppeln konnte sich bei HDMI nicht durchsetzen.

Der SoC liefert bereits TMDS über die HDMI Buchse, etwas anderes kriegt man auch nicht. VGA gibt's nur über einen Brückenchip, DisplayPort macht hier schlichtweg gar keinen Sinn - eine Konvertierung in diese Richtung wäre auch sehr kompliziert und mit recht großen Latenzen verbunden.

Bei den USB "Adaptern" handelt es sich um vollwertige Grafikkarten, sie erweitern nicht einfach die verfügbaren Schnittstellen sondern sind allen Einschränkungen die mit dem Handhaben von mehreren Grafikkarten verbunden sind unterworfen - der SGX Treiber ist weder für so etwas gut geeignet, noch gibt es für diese USB Chips überhaupt eine nennenswerte Linux Unterstützung abseits der alten USB 2.0 DisplayLink Teile.

Danke für die Antwort!
*Da DVI (leider) nicht breit verwendet wird wird man von diesem schönen Stecker absehen können.
(Ich mag Steckkontakte mit Schrauben einfach aber das ist eine andere Diskussion)
*um VGA sieht's demnach nicht so gut aus schade.
*Displayport wird ja noch viel weniger verwendet als DVI ... und der Stecker hat dieselben Nachteile wie HDMI. (Habe schon einige kaputte Buchsen gesehen aber Offtopic)

Jetzt kann ich mir schon etwas mehr vorstellen was in der Dockingstation realisiert wird.
 
Willhelm said:
*Displayport wird ja noch viel weniger verwendet als DVI ...
DisplayPort gehört die Zukunft. Im Gegensatz zu allen anderen Schnittstellen werden keine rohen Bilddaten mit einer zur Auflösung und Wiederholfrequenz synchronisierten Übertragungsfrequenz übermittelt, sondern richtige Datenpakete mit einer festen Frequenz übertragen, die vom Bildschirm ausgewertet und zeitlich einsortiert werden müssen. Über die so ebenfalls übertragbaren Metadaten und den zusätzlichen bidirektionalen Kanal für Nutzdaten ist die Schnittstelle ähnlich universal wie USB einsetzbar - inkl Hubs, Daisy Chaining, Audio, Netzwerkverbindungen... Das macht jene Konvertierung aber auch so problematisch, selbst wenn man sich nur auf die Bildübertragung beschränkt.

Bei Monitoren hat sich DisplayPort schon längst durchgesetzt, lediglich die Multimedia Industrie fährt mit der Weiterentwicklung von HDMI einen sehr strikten Gegenkurs - abgesehen von Panasonic will niemand diesen konkurrierenden Standard bei TV Geräten unterstützen.
 
Dual Link DVI tut's bei mir daheim, damit ich auf 144Hz komme; ansonsten bräuchte ich das nicht.
Da bringt ihr mich auf eine Frage: HDMI überträgt Audio und Video - ist ein Splitter dafür aufwändig zu realisieren? Ich mein, wenn nur an einen TV angeschlossen, ist HDMI i.O.; aber wenn ich das Geraffel an meinen PC-Monitor anschließe, brauche ich 'ne 3,5er Klinke oder dieses optische Digitaldingens zur Anlage. Oder läuft der Pyra Sound gleichzeitig auf Kopfhörerausgang und HDMI? Dann wär's quasi egal.
 
kuru said:
Dual Link DVI tut's bei mir daheim, damit ich auf 144Hz komme; ansonsten bräuchte ich das nicht.
Dual Link hat den Nachteil, dass es auch die doppelten Ressourcen benötigt - und eine Grafikkarte hat in der Regel nur 2 PLLs (selten: 3) für nicht-DP Monitore zur Verfügung. Hier stellt Polaris nebenbei einen Rekord auf: nach der Hardware Dokumentation kann man die bis zu 6 Bildschirme auch ohne DisplayPort füttern.
kuru said:
Da bringt ihr mich auf eine Frage: HDMI überträgt Audio und Video - ist ein Splitter dafür aufwändig zu realisieren?
HDMI nutzt kein S/PDIF sondern einen eigenen Standard (unter anderem weil Consumer S/PDIF nur Stereo beherrscht, HDMI 1.2 liefert bis zu 8 Kanäle). Will man das Audiosignal abgreifen, muss man es vorher konvertieren.
kuru said:
Oder läuft der Pyra Sound gleichzeitig auf Kopfhörerausgang und HDMI? Dann wär's quasi egal.
Warum soll das nicht möglich sein? Wir nutzen ja kein Windows, welches ohne spezielle Unterstützung des jeweiligen Programms nur einen Ausgang mit Daten beliefern kann...

Ich weiß aber nicht wie HDMI hier verkabelt ist, der angepeilte TWL6040 hat lediglich 4 analoge Ausgänge und wird über eine proprietäre Schnittstelle mit Daten versorgt - möglicherweise wird das ganze aber auch einfach über das Audio-Subsystem des SoCs einheitlich angesteuert und erscheint wirklich nur als ein anderer Ausgang. Bei den PCs wird - insbesondere bei dedizierten Grafikkarten - häufig ein eigener Audiochip für HDMI verwendet, das macht die Sache ein klein wenig problematischer.
 
HDMI - Audio:
Mir ist unter Pulseaudio aufgefallen dass hdmi hier als eigenes ziel dargestellt wird. Du kannst über Pulseaudioseite entscheiden 'wohin' jeder einzelne Audiostream hin soll:

https://1.bp.blogspot.com/-IjvgyhHcjFc/VvzxsVY0YzI/AAAAAAAAXe4/LiaDZ7QvKyoGrj8tErRoepqPiW5KGayog/s1600/pavucontrol_chromecast_ubuntu.png

ein besseren Screenshot habe ich gerade nicht gefunden.

https://askubuntu.com/questions/78174/play-sound-through-two-or-more-outputs-devices
hier wird auch beschrieben dass man audio an alle audio devices gleichzeitig senden kann.

Mit Pulseaudio wird die Pyra Sound um einiges besser handeln können als die Pandora.
 
Willhelm said:
Mit Pulseaudio wird die Pyra Sound um einiges besser handeln können als die Pandora.
"Flexibler" passt wohl eher, ALSA selbst ist bereits ziemlich mächtig und kann einiges was bei PulseAudio nicht oder nur sehr umständlich über kaum dokumentierte Optionen erreicht werden kann. Der wesentliche Unterschied liegt darin, dass ALSA maßgeblich über eine komplexe Konfigurationsdatei konfiguriert wird und im laufenden Betrieb nur eine sehr eingeschränkte Auswahl an dynamischen Einstellungsmöglichkeiten bietet.

Ich habe zB meine ALSA Konfiguration so angepasst, dass ich einem Programm via Umgebungsvariable eine andere Soundschnittstelle zuweisen kann.

Letztendlich ist PulseAudio aber auch nur eine zusätzliche Abstraktionsschicht für ALSA. Man kann weiterhin problemlos unter dem Hintern von Pulse an der ALSA Konfiguration herumschrauben wie man lustig ist und sogar die eingehenden Audioverbindungen die zum Daemon umgeleitet werden sollen vorab modifizieren. Problematisch sehe ich allerdings, dass PulseAudio sich nicht nur die Audiostreams über ein ALSA Plugin zum Daemon umleiten lässt, sondern direkt eine eigene Audioschnittstelle anbietet - irgendwo findet sich immer ein Idiot der nur PulseAudio unterstützt und ALSA als kleinsten gemeinsamen Nenner ignoriert, wie zB die Deppen von Overkill, die es bis heute nicht geschafft haben, dass ihr Spiel trotz SDL(!!!) ohne laufenden PulseAudio Daemon überhaupt erst startet :dash:
 
Stimm ich zu.

Alsa ist sehr mächtig. Ich habe an meiner Pandora auch Bluetooth & Internes Mic zum Laufen gebracht. Auch wenn ich mich in config files heimisch fühle sind die von alsa doch etwas weniger leicht zugänglich.
Pulseaudio schiebt einen Layer dazwischen, das schöne daran ist dass es für diese Logik viele klicki bunti GUIs gibt die 'den normalen anwendungsfall' abdecken.
Inwiefern Sonderfälle und deren config files einfacher / verständlicher sind kann ich nicht abschätzen.
Unschön bei der Pandora finde ich das einige Anwendungen nur die default ALSA Ausgabe ansprechen können, mir scheint es so dass Anwendungsentwickler bei ALSA um so etwas explizit kümmern müssten, bei Pulseaudio wird es Pulseaudio überlassen.
Einige Anwendungen hatten mein schön konfiguriertes BT Headset nicht in der Auswahl angeboten. Von dem Mic am BT Headset mal nicht zu reden.

Eine Pulseaudioschnittstelle aus Entwicklersicht vorauszusehen finde ich auch eher als ungünstig.
Vielleicht einigen wir uns auf bequemer, aufgeblähter, GUI freundlicherm, '''convinient'''
:hurra:
 
Willhelm said:
Ich habe an meiner Pandora auch Bluetooth & Internes Mic zum Laufen gebracht.
:hurra:
Oh dann hätte ich da eine Offtopic Anfrage an dich. :)
Könntest du eventuell das Interne Microfon unter dem Telegram Messenger zum Laufen bringen auf der Pandora?
 
Willhelm said:
Auch wenn ich mich in config files heimisch fühle sind die von alsa doch etwas weniger leicht zugänglich.
Die Grundstruktur ist ja noch einfach, richtig lustig wird es mit LADSPA Plugins und @func Makros RTFM
Willhelm said:
Unschön bei der Pandora finde ich das einige Anwendungen nur die default ALSA Ausgabe ansprechen können, mir scheint es so dass Anwendungsentwickler bei ALSA um so etwas explizit kümmern müssten
Da gibt es aber immer noch reichlich Stellschrauben, man kann zB über ALSA_CONFIG_PATH eine eigene asoundrc Datei vorgeben und darin default beliebig umbelegen - brauche ich für Grim Fandango, da dieses Spiel dank seiner PulseAudio Orientierung zwar ALSA unterstützt, aber dabei eine so abstruse konstante Buffer Konfiguration verwendet, dass der Ton nicht sauber wiedergegeben werden kann, wenn ich nicht die Buffer Konfiguration meiner Soundkarte so vergewaltige, dass andere Programme damit einfach abstürzen.

SDL hat hierfür übrigens die AUDIODEV Umgebungsvariable.
 
Back
Top