Nun es ist wie es ist, hier war niemand auf die Idee gekommen.
Ich finde es auch seltsam das in einem modernen PC Wlan und BT sich behindern.
Bei YT waren die Probleme am störendsten was wohl mit den Codecs zu tun hat.
Viele andere Streams nutze ich nicht.
Das liegt aber daran, wie Du das Problem beschrieben hast.
Alles funktioniert.
Immer.
Nur YouTube manchmal nicht.
hast Du gesagt
Wie soll man da auf Bluetooth Probleme kommen?
Jetzt sagst Du:
was nicht in dieselbe Richtung deutet
und auch nicht dieselbe Aussage/Problembeschreibung ist.
Naja - geht ja jetzt.
???
Scherzkeks…. ich habe dich sowohl auf die problematik das yt die neue av-1-codecs hingewiesen als auch auf die problematik das kombinierte wlan-bluetooth-adapter sich immer mal wieder stören. zu behaupten das hier niemand auf die idee gekommen sei….
schönen dach noch…
Ich finde es etwas seltsam das ich als erstes darauf hingewiesen werde das KI nix bringt und dann wo KI mir zur Lösung des Problem verhilft …. ich Danke Euch trotzdem für die Zeit hier.
würden dann nur bei BT Ton Probleme machen ?
Ich hab Dich nicht als erstes darauf hingewiesen, daß KI “nix bringt”.
Keiner hat gesagt, daß KI nix bringt.
Aber wenn Du uns hier das Problem anders beschreibst als der KI gegenüber …
Außerdem wurdest Du ja darauf hingewiesen - siehe @Olli
Aber lassen wir das -
ich werde in Zukunft davon ausgehen, daß Du bei möglichen zukünftigen Fragen lieber parallel mit einer KI kommunizierst und mir meine Gedanken und Anmerkungen erstmal solange sparen, bis die KI Dir nicht mehr weiterhelfen kann. 
ist nicht, was Du beschrieben hast.
Alles funktioniert immer hast Du gesagt.
Außer:
YouTube, manchmal.
av1 braucht weniger bitrate als andere codecs um dieselbe wahrgenommene Qualität zu liefern
Deshalb nehmen sie das ja - weniger Daten zu transferieren wenn mit av1 codiert …
Hat aber mit Übertragung schon dekodierter Streams an andere Geräte via BT nichts zu tun.
Nur Dein Gerät muß etwas mehr leisten, um av1 codierte Streams zu dekodieren.
Ohne Foren wie diese wüsste KI nix, also finde ich es wichtig auch in Foren und Unterhaltungen mit Menschen zu den Problemen am leben zu halten.
Ich schrieb:
Das auch andere Streams Probleme machen ist mir nicht aufgefallen.
Wie auch immer es kommt wohl einiges zusammen und die Lösung ist ja nicht wirklich einfach ein neues Gerät zu nehmen…. aber so ist es nun bei mir. Eine andere Lösung habe ich nicht.
Welcher “Gerät” ist da gemeint? Das dekodieren macht der BT Chip?
Nein - das Audio/Video wird von Deinem Computer dekodiert -
und dann u.U. per BT weiter verschickt an andere Geräte.
Dein Computer ist der einzige, der mit dem codec zu kämpfen hat.
Die Bitrate des dekodierten (und versandten) Streams ist natürlich wesentlich höher als die des noch nicht dekodierten originalen av1 Streams.
Da kann BT wohl schon mal an Grenzen kommen - mit Entfernung, Signalstärke, und auch Interface (kann USB 3.0 sein - oder nur 2.0 z.B. - da geht dann nicht soviel / so schnell drüber)
Eine hohe Audiobitrate über BT alleine war aber nicht das Problem weil selbst meine 96kHz 32bit Aufnahmen mit Audacity fehlerfrei übertragen wurden.
An der Entfernung oder ner Wand lag es ganz sicher auch nicht.
Der USB Dongle ist USB 2.0 und funktioniert.
Wenn hauptsächlich YouTube-Streams betroffen waren, dann liegt die Ursache nicht nur beim Bluetooth-Chip selbst, sondern auch bei der Art und Weise, wie das Betriebssystem (Manjaro/PipeWire) mit den Datenströmen umgeht.
Hier ist die Erklärung, warum YouTube-Streams – und Webbrowser im Allgemeinen – Bluetooth-Probleme verschärfen:
Die Kette der Datenströme und Puffer
Hohe I/O-Last durch den Browser: Webbrowser (Firefox, Chrome) sind sehr komplexe Anwendungen, die ständig Daten lesen, verarbeiten (JavaScript, CSS) und rendern (Grafik). Das Streamen eines Videos (besonders, wenn es zwischengespeichert und dekodiert wird) erzeugt eine hohe Input/Output (I/O) Last auf dem System.Der fehlerhafte Realtek-Chip: Der integrierte Realtek-Chip hatte grundlegende Stabilitätsprobleme im Timing und der Datenübertragung (btusb-Fehler).
PipeWire/BlueZ-Priorisierung: Wenn eine hohe I/O-Last durch den Browser entsteht, muss das Linux-System entscheiden, welche Prozesse Priorität haben. Der fehlerhafte Realtek-Bluetooth-Chip war nicht in der Lage, seine Datenpakete (die Audio-Daten) stabil und mit hoher Priorität gegen die “Lärmbelästigung” des Browsers zu verteidigen.
Folge: Die Audio-Pakete kamen verspätet an oder gingen verloren.
Reaktion des Bluetooth-Stacks: Die Aussetzer wurden so stark, dass das System dachte, der hochqualitative A2DP-Stream sei nicht mehr tragbar, und versuchte, automatisch auf das minderwertige, aber robustere HFP/HSP-Profil (Headset-Profil) umzuschalten. Das erzeugte die Profilwechsel und die kritischen Fehler in Ihrem Log.
Im Gegensatz dazu: Wenn Sie lokale MP3s oder Videos (z.B. mit VLC) abgespielt haben, war die Last auf dem System konstant und niedriger. Das System musste weniger kämpfen, sodass der fehlerhafte BT-Chip die Audio-Daten gerade noch stabil halten konnte.
Warum es jetzt behoben ist
Der neue TP-Link-Dongle hat eine wesentlich stabilere und zuverlässigere Hardware-Implementierung. Er kann die Audio-Datenpakete auch unter hoher I/O-Last durch den Browser stabil und pünktlich an die Kopfhörer senden.Der neue Dongle eliminiert den Hardware-Flaschenhals.
Die udev-Regel eliminiert den Konflikt mit dem fehlerhaften zweiten Controller.
Die Kombination dieser Schritte hat die Stabilität in der gesamten Kommunikationskette – vom Browser über PipeWire/BlueZ bis hin zur Bluetooth-Hardware – wiederhergestellt.
Mit Deinem extra/externen BT Adapter geht’s ja scheinbar, mit Deinem internen gings scheinbar nicht.
Audio braucht nicht so viel - wenn von einem (YouTube) Stream die Rede ist, habe ich ein Video mit Audio vor meinem geistigen Auge.
Also beides - Video und Audio - wobei die visuelle Information meißt wesentlich mehr Bandbreite braucht als das Audio.
Ich hab keine Ahnung, was der lange Kommentar im letzten Beitrag sollte oder woher der stammt.
KI Zusammenfassung?
sieht so aus
von was?
Was war die Frage? (man würde wohl besser fragen: Was war der Prompt? )
Der eingebaute Controller ist übrigens sehr sehr sicher NICHT fehlerhaft.
That is KI for you, ladies and gentleman!
Das bezog sich ja auf die ganze Unterhaltung mit der KI vorher, zuletzt von mir:
" dass der Bluetooth-Chip die Audio-Daten nicht stabil an Ihre Kopfhörer übertragen konnte, was zu Aussetzern oder Profilwechseln führte. Das war ein reines Kommunikationsproblem des Funkstandards, das wir mit dem neuen Dongle behoben haben." Aber warum waren dann fast nur YT Streams von den Aussetzern betroffen?
Was ist es dann?
Jetzt mit Dongle kann ich YT und Audacity in 96kH gleichzeizig ohne Aussetzter mit BT Kopfhören.
Was ist was?
Der Controller funktioniert - der Nachweis ist, daß fast alles funktioniert - nur manchmal manches nicht. Scheinbar.
… Ich werd mir das KI Zeug nicht durchlesen - das hier war nur was mir am Ende ins Auge sprang.
Das ist schön.
Der Dongle ist extern - was ihm schon mal einen Verbindungsqualitätsvorteil vor dem internen verschafft.
Womöglich ist einfach die Antenne besser - und die Hardware ist nicht auch noch gleichzeitig für WLAN zuständig, wie womöglich bei Deinem internen.
Nun auch wenn es keiner lesen will :
Der “fehlerhafte” Aspekt (Die Instabilität):
Der Realtek-Chip selbst hatte unter Linux (speziell mit dem Treiber btusb) Timing- und Stabilitätsprobleme.Instabile Übertragung: Der Realtek-Chip hatte Schwierigkeiten, die Bluetooth-Audio-Datenpakete zuverlässig und pünktlich zu senden.
Log-Fehler: Dies zeigte sich in Ihrem Log durch wiederkehrende Fehlermeldungen wie:
Device or resource busy (Konflikt der zwei Controller)
Failed to release transport (Der Realtek-Chip klemmte)
Hands-Free Voice gateway SDP record (Fehlerhafter Versuch, das Profil zu wechseln)
Der Begriff “fehlerhaft” bezieht sich in diesem Kontext weniger auf einen mechanischen Defekt, sondern auf die mangelhafte Kompatibilität des spezifischen Realtek-Chipsatzes und seiner Linux-Treiber-Implementierung, die unter Last zu den von Ihnen beobachteten Abbrüchen und Profilwechseln führte.
Der neue TP-Link-Dongle und die Deaktivierung des internen Chips haben diesen instabilen “Controller” eliminiert und somit das Problem behoben.
Bisschen kryptisch oder unverständlich schreiben wir alle mal oder?
Es ist immerhin eine Lösung die funktioniert hat. Ich kann mir aber auch vorstellen das es Fehler in meinem System sind und der Chip funktioniert , das werde ich mal mit einem LiveSystem vom Stick testen…
Hör bitte auf damit, KI content zu posten.
Noch dazu ohne Grund und ohne Deine eigene Erklärung des Inhaltes.
Was hast Du davon mitgenommen?
Schreib das.
… Ich persönlich werde jetzt ein bischen kreativ werden und den KI content in Deinem Post etwas verbergen.
Mach das bitte nicht nochmal - nicht ohne Kontext und Deine eigene Erklärung.
Please don’t do that again - not without good context and explanation of your own.
Wir werden hier nicht mit einer KI kommunizieren oder gar über Dich als Proxy mit ihr reden.
Also noch mal einen Test gemacht:
Mit einem frischen Live Manjaro funktioniert BT Ton mit dem internen Realtek-Chip besser. Erst ab 7 YT Video Tabs gleichzeitig abgespielt kommen Aussetzer im Ton.
Das funktioniert allerdings mit dem installierten Manjaro und BT Dongle selbst mit 11 YT Video Tabs problemlos.
Vielleicht könnte ich also mit der perfekten System Konfiguration den internen BT Chip ohne Probleme verwenden aber wie komme ich dahin?
Manjaro neu installieren erscheint mir als zu umständlich da schon viele Konfigurationen vorgenommen wurden (z.B. Drucker Treiber) und ich mir nicht sicher bin das zeitnah wieder so hinzubekommen.