softhddevice-drm: Alsa Verbesserungen

zillerbaer · 26. Mai 2021

Im git habe ich die Art der Soundkarten Konfiguration umgeschrieben. Es wird Alsa konfiguriert nach den Parametern des Streams. Was Alsa nicht kann wird dann im AudioFilter angepasst. jsffm , dabei habe ich auch eine Funktion wieder eingeführt die bei 6-Kanal Ton die Channel von ffmpeg Format zu Alsa Format umsortiert.

Hier habe ich eine Aureon51MkII USB Soundkarte die eigentlich 6 Kanäle beherrscht. Die funktioniert aber mit 6 Kanälen nicht. Es ist nur Blubbern zu hören. Mit Stereo Setting funktioniert sie tadellos.

Bitte testet das mal mit unterschiedlicher Audio HW und gebt mir Bescheid ob das funktioniert. Besonders an Tests mit 6 Kanal und Audiomaterial mit hoher sample Rate bin ich interessiert. Die Auflösung ist aktuell fest auf 16 Bit gestellt. Hat jemand HW die 32 Bit kann? Dazu bitte SOUND_DEBUG im Makefile einschalten.

Gruss

zille

jsffm · 26. Mai 2021

Erst die gute Nachricht, 5.1 funktioniert.

Schlechte Nachricht, Channelmapping funktioniert bei eac3 und aac nicht, ac3 scheint ok. Testen ist schwierig, da meine Tests ohne Bild dargestellt werden.

jsffm · 26. Mai 2021

ac3 ist auch nicht korrekt

center -> surround left

right surround > center

zillerbaer · 26. Mai 2021

Zitat von jsffm

Erst die gute Nachricht, 5.1 funktioniert.

Dann ist wohl die USB Sound Karte das Problem.

Umsortiert wird momentan von ffmpeg L R C LFE Ls Rs -> alsa L R Ls Rs C LFE. Ist das falsch? Das kann auch abgeschaltet werden indem diese Zeile mit // auskommentiert wird. Ändert sich dann am Channel map etwas? Ich kann das leider nicht testen da ich keine funktionierende 6 Kanal HW habe.

jsffm · 26. Mai 2021

Im Moment habe ich ein andres Problem, auf aktuellsten kernel umgestellt und dann geht hevc nicht mehr, da muss ich jetzt wieder was funktionierendes finden

jsffm · 26. Mai 2021

Mein Problem gelöst, 3.10.39 ging nicht, 3.10.38 auch nicht, zurück zu 3.10.25 funktioniert.

6-Channel kurz angetestet, hört sich besser an, genaueres später.

Ich hatte auch mal ne USB-Soundkarte genutzt und wenn ich mich richtig erinnere, musste ich da die Channels mappen.

zillerbaer · 26. Mai 2021

Zitat von jsffm

auf aktuellsten kernel umgestellt und dann geht hevc nicht mehr

Es ist immer die Kombination Kernel / FFmpeg. Wenn im Kernel etwas angepasst wird braucht man auch die entsprechende FFmpeg Version die damit umgehen kann.

Zitat von jsffm

6-Channel kurz angetestet, hört sich besser an, genaueres später.

Kein Stress! Wir haben Zeit.

jsffm · 26. Mai 2021

Ich habe die aktuellste Version von dem Branch, allerdings nicht neu compiliert. Kernel Updates mache ich per rpi-update und der kümmert sich wohl nicht um header-files.

jsffm · 8. Juni 2021

Zitat von zillerbaer

Bitte testet das mal mit unterschiedlicher Audio HW und gebt mir Bescheid ob das funktioniert. Besonders an Tests mit 6 Kanal

Ich bin leider erst jetzt dazu gekommen, das besser zu Testen. Mit folgendem Patch hört sich das korrekt an:

Diff

diff -u audio.c.s audio.c
--- audio.c.s   2021-05-26 16:48:43.569529730 +0200
+++ audio.c     2021-06-08 18:14:27.934026575 +0200
@@ -198,10 +198,10 @@
                                lfe = buf[i + 3];
                                ls = buf[i + 4];
                                rs = buf[i + 5];
-                               buf[i + 2] = ls;
-                               buf[i + 3] = rs;
-                               buf[i + 4] = c;
-                               buf[i + 5] = lfe;
+                               buf[i + 2] = lfe;
+                               buf[i + 3] = c;
+                               buf[i + 4] = ls;
+                               buf[i + 5] = rs;
                        }
                        break;
                case 8:

Alles anzeigen

jsffm · 8. Juni 2021

oder auch so:

Diff

diff -u audio.c.s audio.c
--- audio.c.s   2021-05-26 16:48:43.569529730 +0200
+++ audio.c     2021-06-08 18:34:22.548526865 +0200
@@ -196,12 +196,12 @@
                        for (i = 0; i < size; i += 6) {
                                c = buf[i + 2];
                                lfe = buf[i + 3];
-                               ls = buf[i + 4];
-                               rs = buf[i + 5];
-                               buf[i + 2] = ls;
-                               buf[i + 3] = rs;
-                               buf[i + 4] = c;
-                               buf[i + 5] = lfe;
+                               // ls = buf[i + 4];
+                               // rs = buf[i + 5];
+                               buf[i + 2] = lfe;
+                               buf[i + 3] = c;
+                               // buf[i + 4] = ls;
+                               // buf[i + 5] = rs;
                        }
                        break;
                case 8:

Alles anzeigen

zillerbaer · 8. Juni 2021

Das verwundert mich jetzt! Dann müsste softhddevice schon immer falsch sortiert haben. Testest Du mit ac3 oder aac. Nicht das die Formate auch noch eine untersciedliche Sortierung der Kanäle haben?

jsffm · 8. Juni 2021

ac3 länger, aac und eac3 kurz angetestet

zillerbaer · 8. Juni 2021

Ich muss mir das noch mal genauer anschauen. Das ist für mich nicht richtig nachvollziehbar. Wie ist das bei den anderen softhddevice Abkömmlingen? Da müsste das selbe Problem auch auftreten. Kann jemand den Patch von Jürgen gegen checken?

zillerbaer · 27. Juni 2021

jsffm , ich kann das theoretisch nicht nachvollziehen. Eigentlich sollte das Sorting wie es Johns geschrieben hat stimmen. Da Du das aber getestet hast und es keine andere Meinung gibt habe ich Deine zweite Variante eingecheckt.

speed · 9. Juli 2021

Hallo,

habe gerade mal versucht das Plugin dfatmo zum laufen zu bringen.

Ich habe noch einen Fernseher, wo ich so ein altes Ambilight dran habe.

Mit dem rpihddevice läuft das top, und mit dem Softhddevice ging das früher auch.

Aber mit dem softhddevice-drm passiert einfach nix.

Hat das einer von euch am laufen ?

Gruss

speed

zillerbaer · 9. Juli 2021

Die Schnittstelle wird von softhddevice-drm nicht bedient. Ich werde mal schauen wie hoch der Aufwand ist das zu integrieren. Was wird dazu benötigt?

speed · 9. Juli 2021

Wie meinst du das " Was wird dazu benötigt " ?

zillerbaer · 9. Juli 2021

Das Atmo Plugin braucht irgendwelche Daten. Wie müssen die aussehen? Was sollen die beinhalten?

speed · 9. Juli 2021

Hier mal den Link, wo durchflieger es damals passend für das softhddevice gemacht hat .

[softhddevice][patch] Verbesserter Grab Support

zillerbaer · 9. Juli 2021

Da sehe ich keine Chance das zu integrieren. Atmo will ein RGB Bildformat das nicht zugänglich ist. Das Bildmaterial ist in YUV Formaten, die meistens noch eine Hersteller spezifische Sortierung der Pixel hat. Diese Herstellerformate kennt FFmpeg nicht so das eine Konvertierung nicht möglich ist.

softhddevice-drm: Alsa Verbesserungen

Jetzt mitmachen!

Teilen

Tags