SHIFTphone 8 gibt ein "Pock" beim Starten einer Audiowiedergabe von sich

jxn_30

Active member
Original poster
26 Oktober 2024
86
Hallo zusammen,

ich bin sehr zufrieden mit meinem neuen Gerät, es gibt allerdings eine Sache, die mich etwas fuchst: Immer, wenn das Gerät beginnt, eine Audiodatei abzuspielen, kommt ein kurzes "Pock", selbst dann, wenn alle Lautstärkeregler auf 0 gestellt sind. Das passiert zum Beispiel beim Starten oder Fortsetzen der Wiedergabe in Spotify, aber auch beim Scrollen durch Social-Media oder bei Spielen, die keinen dauerhaften Ton abspielen, passiert das. Ich habe ein bisschen gebraucht, um herauszufinden, woher das kurze "Pock" kommt, bis ich es jetzt darauf zurückführen konnte. Dementsprechend lässt sich das auch sehr gut reproduzieren.
Das "Pock" kommt nicht immer sondern lediglich, wenn seit dem letzten Beenden eines Audiosignals eine Pause von mind. ca. 4 Sekunden war. Festzustellen ist es auf allen Lautstärkestufen, von ganz aus bis ganz laut, wenn man aber einen Ton vom Gerät erwartet stört es nur, wenn man es weiß. Erwartet man jedoch keinen Ton vom Gerät, ist es durchaus etwas nervig :)
Ist ein Kopfhörer angeschlossen (in meinem Fall per Bluetooth), tritt das Phänomen nicht auf. Lenke ich die Audioausgabe (wenn ich Spotify laufen hab, kann ich ja auswählen, ob die Ausgabe an den Lautsprecher oder die Kopfhörer geschickt werden soll) wieder auf die Lautsprecher, kommt das "Pock" jedoch wieder.
Ich nutze aktuell als Betriebssystem: SOS.6.0.20241128 release-keys.

Anbei ein Video, in dem das ganze zu hören ist, hier am Beispiel Spotify. Während des Experiments waren alle Lautstärkeregler auf 0 gesetzt (das hatte ich leider vergessen, mit im Video zu zeigen). Man hört immer, wenn ich auf den Play-Button drücke und eine gewisse Zeit seit der letzten Wiedergabe vergangen ist, ein "Pock", zusätzlich zu meinem Finger-Tatscher. Ich habe auch zwischendurch etwas schneller zwischen Wiedergabe und Pause gewechselt, hier kann man kein "Pock" hören sondern nur meine Finger-Tatscher.


Hat jemand schon ein ähnliches Phänomen beobachten / hören können? Gibt es vielleicht sogar schon einen Thread oder einen Post, in dem das ebenso beschrieben wurde, den ich aber einfach noch nicht gefunden habe?

Viele Grüße
 

Anhänge

  • screen-20241214-224555.mp4
    23,5 MB
Zuletzt bearbeitet:
Stimmt - jetzt merk ichs auch. 👂
Es "pockt". Wenn die Musik für 3 oder 4 Sekunden aus war und dann wieder startet...
Hatte bislang nie drauf geachtet , bin mal gespannt, ob's mir jetzt öfter auffällt.
SP8, 6.8G
 
@amartinz ich habe mir das Thema einmal näher betrachtet, weil es gefühlt häufiger vorkommt.

Vorweg: Ich kenne mich mit der Entwicklung von Android bzw. dem Audio-Stack selbst nicht besonders gut aus. Ich interessiere mich aber sehr für Technik und wollte deshalb versuchen, das Problem etwas genauer einzugrenzen. Dabei habe ich mir auch mit ChatGPT bei der Analyse der ADB-Logs helfen lassen, welcher folgende Kommentare und Hinweise verfasst hat.

Es gibt einen kurzen, tiefen „POCK“, wenn eine neue Audioausgabe nach einer kurzen Pause gestartet wird.

Das Interessante:
  • YouTube → POCK
  • Facebook Reels → POCK
  • lokales Video → POCK
  • lokale Audiodatei → POCK
  • Lautsprecher → POCK
  • Kopfhörer → ebenfalls POCK
  • Bluetooth aus
  • Haptik aus
  • Medienlautstärke 0 → POCK trotzdem
Ich konnte inzwischen einen ziemlich zuverlässigen Zusammenhang mit dem Audio-Standby feststellen:

Musik läuft → stoppen → sofort YouTube starten: kein POCK

Musik läuft → stoppen → ca. 10 Sekunden warten → YouTube starten: POCK

Wenn bereits Audio läuft und ich anschließend zu YouTube oder einer anderen App wechsle, kommt ebenfalls kein POCK.

Ich habe dazu per ADB einen fokussierten Audio-Log aufgenommen. Beim erneuten Start des Audiopfades sieht man u. a.:

route_output_stream: enter: usecase(0: deep-buffer-playback)
start_output_stream: enter: ... deep-buffer-playback
enable_snd_device: snd_device(2: speaker)

Danach bei der ACDB-Initialisierung:

ACDB_CMD_GET_AFE_INSTANCE_COMMON_TABLE_SIZE Returned = -19
Error: ACDB AFE returned = -19
und anschließend:

start_output_stream: exit
out_write: retry previous failed cal level set
Beim vorherigen Audio-Standby sieht man:

out_standby
disable_audio_route
disable_snd_device
Ich möchte ausdrücklich nicht behaupten, dass der ACDB AFE -19 definitiv die Ursache ist. Für mich als Laien ist aber der zeitliche Zusammenhang mit dem erneuten Aufbau des deep-buffer-playback-Pfades auffällig.

Vielleicht kannst du einschätzen, ob der -19 hier erwartbar ist oder ob beim Reaktivieren des Audio-Streams etwas nicht sauber läuft.

Wenn du weitere Logs, einen vollständigen bugreport oder bestimmte ADB-Ausgaben brauchst, kann ich gerne nachreichen. :)

Gruß