senfcall, kein Audio

[Arnulf zu Linden]

(03.04.2021 23:54)DosAmp schrieb:  Der Bug dazu, warum media.setsinkid.enabled nicht standardmäßig wie angedacht seit Firefox 63 an ist,

Nach dem Aktivieren von media.setsinkid.enabled in Firefox 68.12.0esr (64-Bit) lassen sich nun auch zwei "Lautsprecher" auswählen. Ein Ton kommt aber immer noch nicht. Beim Versuch den Testton abzuspielen, schmeißt die Console des Debugger:

Code:

HTTP “Content-Type” of “audio/mpeg” is not supported. Load of media resource https://bbb1.senfcall.de/html5client/resources/sounds/audioSample.mp3 failed. join
NotSupportedError: The media resource indicated by the src attribute or assigned media provider object was not suitable.
Cannot play media. No decoders for requested formats: audio/mpeg

gst-ffmpeg, gst-plugin-bad und gst-plugin-ugly sind installiert, deren Fehlen im Internet als eine mögliche Fehlerquelle für obiges angegeben wird.

[Blue]

gstreamer ist seit Firefox 44 kein default mehr. bevorzugt/genutzt wird ffmpeg.


für unkomplizierten mp3 genuss ohne die FSF flagge einpacken zu müssen bietet ffmpeg seit 3.3.1-1 auch mp3 support

Code:

# 3.3.1-1:    20/may/2017 by Eric Hameleers <alien@slackware.com>
#             * Update. After expiry of the MP3 patents, this package will now
#               be able to encode MP3 even in the unrestricted variant.

ich würde wie schon hier erwähnt auch mal gedanken drum machen, entweder bei slackware-dev selber handanzulegen, dass dieses Projekt aktueller wird oder sich nach einer alternativen Distribution umzuschauen. Auf kompilierter Basis wäre Gentoo ja die alternative, sonst wäre sicherlich Arch Linux mit festen Base-Paketen und das AUR zum selber kompilieren die wahl. Du tust dir zumindest im produktiv sein kein gefallen, da werden alle Linux Klischees aus diesen Jahrtausend erfüllt.

[Smaecks]

zumal man mit slackware auch das alles links liegen lässt was linux jüngst schön zu verwenden gemacht hat. und da haben wir die BRANDAKTUELLEN und NEUEN pakete wie man sie in diesem beispiel sieht gar nicht angeschnitten.

[DosAmp]

(04.04.2021 02:21)Arnulf zu Linden schrieb:  Beim Versuch den Testton abzuspielen, schmeißt die Console des Debugger:

Code:

HTTP “Content-Type” of “audio/mpeg” is not supported. Load of media resource https://bbb1.senfcall.de/html5client/resources/sounds/audioSample.mp3 failed. join
NotSupportedError: The media resource indicated by the src attribute or assigned media provider object was not suitable.
Cannot play media. No decoders for requested formats: audio/mpeg

gst-ffmpeg, gst-plugin-bad und gst-plugin-ugly sind installiert, deren Fehlen im Internet als eine mögliche Fehlerquelle für obiges angegeben wird.

Das mag bei mir auch nicht so recht funktionieren (als Abhängigkeit von gst-plugins-ugly müsste natürlich auch mindestens libmad bzw. ffmpeg bei gst-ffmpeg installiert sein), aber der eigentliche Echotest, der wie die Sprachübertragung an sich sicherlich kein MP3 verwendet, funktioniert in einer virtuellen Maschine mit Slackware 14.2 auf aktuellem Stand (das heißt mit Firefox ESR 68.12.0, aber der ursprünglichen angepassten Version von Pulseaudio 9.0) ohne externe Pakete einwandfrei.
Das Durchhangeln durch die KDE4-Menüs für Audio ist etwas gewöhnungsbedürftig, aber Pulseaudio kann man auch gut mit pavucontrol konfigurieren.

[Arnulf zu Linden]

ffmpeg 3.2.2 → 3.4.6: Der Testton erklingt jetzt, aber der eigentliche Echo-Test funktioniert immer noch nicht.

[Playitlouder]

(04.04.2021 09:17)Blue schrieb:  [...]
ich würde wie schon hier erwähnt auch mal gedanken drum machen, entweder bei slackware-dev selber handanzulegen, dass dieses Projekt aktueller wird oder sich nach einer alternativen Distribution umzuschauen. Auf kompilierter Basis wäre Gentoo ja die alternative, sonst wäre sicherlich Arch Linux mit festen Base-Paketen und das AUR zum selber kompilieren die wahl. Du tust dir zumindest im produktiv sein kein gefallen, da werden alle Linux Klischees aus diesen Jahrtausend erfüllt.

Ich kann in Sachen Distri auch noch Manjaro empfehlen. Ist quasi ne Klickibunti Distri für Arch. Alles ist vorkonfiguriert. Und die Defaults sind recht sinnvoll imo. Hat halt den Vorteil, dass man die AUR und n sehr aktuellen Kernel fahren kann, ohne vorher erstmal Stunden mit ner Arch install und Konfiguration zu verschwenden. Klar ist das n bisschen bloatiger als jedes installierte Paket zu kennen etc., aber da bin ich persönlich einfach zu faul zu. Hab das hier seit mindestens 3 Jahren laufen und hab teilweise auch mal n halbes Jahr+ keine Updates installiert und es hat sich bisher nicht zerlegt.
Die Manjaro Paketquellen sind n bisschen hinter den arch repos, aber das find ich eigentlich ganz praktisch, weil so halt jemand anders mal die gröbsten Bugs findet und mein Produktivsystem nicht beeinflusst wird.
Und die AUR ist halt echt praktisch, braucht man mal eben n Treiber für n neuen Bluetooth Stick, der nicht im Kernel ist? Eben mit yay installiert.
Und das Arch Wiki ist halt auch echt n Argument....

Sorry für das in deinem Fall nicht wirklich zielführende derailing des Threads.

[DosAmp]

(04.04.2021 20:36)Arnulf zu Linden schrieb:  ffmpeg 3.2.2 → 3.4.6: Der Testton erklingt jetzt, aber der eigentliche Echo-Test funktioniert immer noch nicht.

Können denn andere Clients über Pulseaudio Ton aufnehmen? Die einfachste Testvariante ist dabei wohl mit den Pulseaudio-CLI-Werkzeugen:

Code:

$ parecord testaufnahme.wav & sleep 10 && kill $!

Audacity ist hierbei nicht ganz repräsentativ, da es nach Möglichkeit direkt ALSA zur Aufnahme oder Wiedergabe verwendet, außer wenn man „pulse“ als Gerät einstellt (wodurch der Pulseaudio-Soundserver als simuliertes Soundgerät von Programmen verwendet werden kann, die nicht wie Firefox direkt das Pulse-Protokoll unterstützen).

[Arnulf zu Linden]

(05.04.2021 12:13)DosAmp schrieb:  Können denn andere Clients über Pulseaudio Ton aufnehmen? Die einfachste Testvariante ist dabei wohl mit den Pulseaudio-CLI-Werkzeugen:

Code:

$ parecord testaufnahme.wav & sleep 10 && kill $!

Mit obigem Code scheitert es am default input device. Mit einem zusätzlichen Parameter funktioniert die Aufnahme.

Code:

parecord -d alsa_input.usb-ZOOM_Corporation_H2n_000000000000-00.analog-stereo test.wav & sleep 10 && kill $!

Code:

pacmd "set-default-source alsa_input.usb-ZOOM_Corporation_H2n_000000000000-00.analog-stereo"

setzt den Zoom H2n als default input device, aber der senfcall Echo-Test funktioniert trotzdem nicht.

[Arnulf zu Linden]

Es funktioniert!

Die im Startbeitrag zu diesem Fred geäußerte Vermutung, dass senfcall unter Linux nicht damit klar kommt, dass das System mehrere "Lautsprecher" enthält, lag nicht völlig daneben. Die Lösung sieht so aus:

1. ffmpeg ≥ 3.3.1 muss installiert sein, damit mp3, dessen Patentschutz vor 'n paar Tagen abgelaufen ist, unterstützt wird. (Das wird möglicherweise nur für den Testton benötigt, aber egal.)
2. Bei PulseAudio müssen z. B. mit pavucontrol (menu: Configuration) alle devices – außer dem Zoom H2n als analog input device und der Audigy 2ZS als analog output device – auf "Off" gestellt werden, womit PulseAudio nur noch genau ein input device und genau ein output device bereit stellt.
   

Erfolgreich getestet wurden der Echo-Test und eine "Konferenz" mit dem Arbeitsrechner am Platz, wobei dieser PC nur zuhören kann. Das Zoom H2n hängt ja direkt am Software-Ausprobierrechner, wohingegen der Kopfhörer an einem Verstärker hängt, an den beide PCs jeweils mit line-out angeschlossen sind. Zum Testen ist z. B. eine Stimmgabel praktisch, da bei der anders als bei der eigenen Sprache Körperschall (im eigenen Kadaver) nahezu keine Rolle spielt.

Ach ja, abgesehen von dem einen Upgrade auf ffmpeg 3.4.6 (inoffizielles Paket für Slackware64 14.2 verfügbar) geht es ohne den neuesten Schrei an Software.

[DosAmp]

(05.04.2021 17:15)Arnulf zu Linden schrieb:  Bei PulseAudio müssen z. B. mit pavucontrol (menu: Configuration) alle devices – außer dem Zoom H2n als analog input device und der Audigy 2ZS als analog output device – auf "Off" gestellt werden, womit PulseAudio nur noch genau ein input device und genau ein output device bereit stellt.

Auf diesen Ansatz wollte ich in #14 bereits implizit hinweisen, was mit genau zwei Soundkarten aber etwas missverständlich war.
Schön, dass es jetzt funktioniert.