Galaxy Nexus - Probleme mit der Lautstärke (SAV-Ghost / Volume-Ghost)

[Splasher]

behauptet aber der Google Ingenieur.

Und wenn das alle Handys haben, war das bisher kein Bug, sondern quasi ein akkuspar feauture

 

[toschel]

Hab gerade mal den zitierten Thread mit den Erklaerungen von Lee Johnston gelesen. Dort wurde meine Frage auch diskutiert und ist nach Meinung von Lee normalerweise kein Problem. Das Eventhandling wird in der Regel nicht in der CPU sondern in einem dediziertem Treiberchip oder PGA gemacht, so dass nur "echte" Button-Events an die CPU propagiert werden.

 

[google-loves-data]

Wenn das Apple's iPhone 4S ein ähnlich gravierendes Problem hätte, wäre das in der Mainstreampresse mit entsprechend populistischen Überschriften.

Warum schafft es Google diesen Bug fast geheim zu halten? Samsung ist doch die Nr. 2?

 

[dbum]

Weil die Nexus Handys an der Oberfläche noch nie groß interessiert haben. Außerdem ist das Nexus bislang nur im UK erhältlich.

Mal nebenbei. Ein 'ähnlich gravierendes' Problem wär beim iPhone genau so an der Presse vorbei gegangen. Das Problem ist zwar ein äußerst peinliches Ding, aber leicht zu beheben und betrifft nur einen Teil der Nutzer unter bestimmten Umständen. Gravierend ist das also auf keinen Fall.

 

[Punisher]

Weils vllt 1000 Leute momentan haben und net +1.000.000 ^^

 

[isam2k]

Warum schafft es Google diesen Bug fast geheim zu halten? Samsung ist doch die Nr. 2?

Das SGN ist nicht annähernd so populär wie ein iPhone 4S. Was vielen Faktoren zu verdanken ist:

1. Die Nexen haben einen Ruf als Geek- Phones

2. Schon die Vorstellung des Geräts war für die wenigen Nexus-Fans ein einziger Spiessrutenlauf (verschoben aufgrund einer recht fadenscheinigen Stellungsnahme - der selbst heute noch Gerüchteflair anhaftet)

3. Lausige Kommunikation von Terminen und Specs (man bedenke, dass selbst nach der offiziellen Vorstellung hier im Forum noch über gewisse Specs gemunkelt (ich liebe dieses Wort) wurde.

4. Irgendwie hab ich ausserdem das Gefühl, dass die grossen Magazine mit Spezialgeräten beliefert wurden und spezielle Anweisungen erhalten haben, wenn man bedenkt, wie sehr sich die Fachpresse beim Bug zurückgehalten hat.


Oder aber, die Leute, welche bei der Fachpresse die Tests machen (also Leute, welche Ahnung von guten Smartphones haben) sind alles Android- Geeks und haben absichtlich den Bug etwas heruntergespielt. Hehe

Sent from my Nexus S using Tapatalk

 

[Punisher]

Oder aber, die Leute, welche bei der Fachpresse die Tests machen (also Leute, welche Ahnung von guten Smartphones haben) sind alles Android- Geeks und haben absichtlich den Bug etwas heruntergespielt. Hehe

Sent from my Nexus S using Tapatalk

Wahrscheinlich waren die alle im eigenen W-Lan Netz während des Testes und haben die Telefonfunktion gar net getestet

 

[semper09]

In Amerika scheint der Bug eben nicht reproduzierbar zu sein und da kommen auch die meisten Reviews her.

 

[rauke]

Dass die ganzen blogs nicht neutral sind, sollte klar sein: 1. Leben sie von der Werbung und 2. Sind sie darauf angewiesen, von den Herstellern Testgeräte zu bekommen. Genau darum zieht z.b. die Stiftung Warentest anonym los und kauft testgeräte im laden.

Sent from my Transformer TF10

 

[Lion13]

In Amerika scheint der Bug eben nicht reproduzierbar zu sein und da kommen auch die meisten Reviews her.

Das hat auch einen einfachen Grund - in den USA wird die Frequenz mit 900 MHz nicht verwendet, daher tritt der Fehler dort nicht auf.

 

[he_stheone64]

Oder aber, die Leute, welche bei der Fachpresse die Tests machen (also Leute, welche Ahnung von guten Smartphones haben) sind alles Android- Geeks und haben absichtlich den Bug etwas heruntergespielt. Hehe

Sent from my Nexus S using Tapatalk

Eher weniger, die Medien Fuzzis haben schon historisch fast alle einen Apfel förmigen Kopf

 

[Galactus]

Es tut sich was:

Samsung Galaxy Nexus: Inoffizieller Bugfix für Lautstärke-Problem verfügbar » mobiFlip.de

Galaxy Nexus volume bug fix gets early release, official testing continues -- Engadget

 

[Thyrus]

nur zur info - den einzuspielen bedeutet zu rooten. Falls jemand das nicht machen moechte, bedeutet es warten.

 

[escrivel]

Rooten tu ich eh, nur Custom Roms wollte ich eigentlich nicht mehr nutzen müssen. Naja mal sehen wann da der offizielle fix kommt

 

[sungazer]

Das ist natürlich ein klassischer Fall von dem hier xkcd: Duty Calls:

aber ich antworte trotzdem mal...

Ich will nicht darüber spekulieren, wo der Fehler tatsächlich sitzt, ich finde aber eine Erklärung, wie das Ganze normalerweise technisch funktioniert, angebracht. Wenn man das versteht, muss man sich nämlich auch nicht mehr endlos über Hardware vs. Software streiten.

Sämtliche Hardware-Taster hängen relativ direkt entweder am Baseband-Processor (für die Mobilfunkanbindung zuständig; evtl. auch in einem großen SoC integriert) oder am Application-Processor. Beides sind letztlich einfach nur ARM-basierte Microcontroller und die Leitungen, an die man geht, nennen sich GPIO (General Purpose I/O).

Ich habe "relativ direkt" geschrieben, weil man immer eine Entprell-Schaltung (http://de.wikipedia.org/wiki/Entprellen) zwischen Taster/Schalter und GPIO hängt. Normalerweise ist das ein RC-Glied bestehend aus Widerstand und Kondensator. Ganz Eifrige können noch einen Schmitt-Trigger einbauen, das ist bei modernen Microcrontrollern aber meines Wissens nicht nötig. Wie genau das zu verschalten ist, steht bei jedem Microcontroller, der mir bislang untergekommen ist, in der Dokumentation - mit Schaltplan und vorgeschlagener Dimensionierung der Bauteile. Hält man sich daran, so ist Prellen kein Thema mehr. Wenn das bei dem Galaxy Nexus nicht funktioniert, hat hier jemand seine wirklich einfachsten Hausaufgaben nicht gemacht. Schlimmer noch: Das fällt normalerweise bei Tests auf (Stichwort EM-Prüfung) und wirft schon Zweifel an Qualität und Qualitätssicherung bei Samsung auf.

Nun ist das möglicherweise prellende Eingangssignal aber noch nicht in Software angekommen und somit noch nicht alles zu spät, sondern man kann noch tricksen (das hat aber mit sauberem Hardware-Entwurf dann nichts mehr zu tun). Der Anwendungsfall, auf ein Rechtecksignal bei steigender (Taster gedrückt) oder fallender Flanke (Taster losgelassen) ist glücklicherweise so häufig, dass es dafür Vorkehrungen in Hardware gibt. Man sagt dem Microcontroller (aus einer Software-Routine heraus) also, dass man bei so einem Ereignis gerne einen Interrupt hätte, was dazu führt, dass der Microcontroller seine Arbeit unterbricht und in eine zur Bearbeitung dieses Ereignisses hinterlegte Software-Routine (Interrupt-Handler oder Interrupt Service Routine) springt.

Unter welchen Bedingungen das geschehen soll, kann man konfigurieren. Insbesondere kann man einstellen, wie lange das Signal schon stabil sein muss, bevor der Interrupt ausgelöst wird. Die Überprüfung dessen erfolgt im Microcontroller in Hardware und sollte keine CPU-Zyklen fressen. Damit kann man einen ähnlichen Effekt wie mit einem RC-Glied erreichen, es ist aber nicht das gleiche, da ein RC-Glied tatsächlich die ungewünschten hohen Frequenzen filtert und man hier nur hohe Frequenzen für eine Weile ignoriert. Das löst das Problem nicht, sorgt aber dafür, dass es deutlich weniger auftritt (und sich weniger Kunden beschweren).

Jetzt gibt es noch eine dritte Möglichkeit, wenn man obige Maßnahmen nicht ergriffen hat, oder das nicht funktioniert hat: Man kann im Interrupt-Handler einen Timer auslesen und die aktuelle "Zeit" (eine Zahl) mit der beim letzten Aufruf des Interrupt-Handlers gespeicherten vergleichen. Das ist natürlich fatal, da dies vollständig in Software geschieht und jedes Mal gemacht werden muss, wenn eine Stör-Flanke anliegt. Mit Pech (viel Störungen) kommt die CPU dann zu nichts anderem mehr.

Jetzt muss ich noch eine Einschränkung loswerden: Man muss GPIOs nicht per Interrupt behandeln, man kann auch pollen, d.h., regelmäßig in Software nachschauen, ob das Signal bei logisch 0 oder 1 ist, aber der Optimist in mir hofft, dass so ein Unsinn bei aktuellen Handys nicht mehr gemacht wird.

--sg

 

[toschel]

Hi Sungazer, ist wohl nicht so schlimm, weil das Entprellen bzw. das Eventhandling in einem fPGA sitzt und nur echte Events an die CPU gemeldet werden.

Jetzt muss ich noch eine Einschränkung loswerden: Man muss GPIOs nicht per Interrupt behandeln, man kann auch pollen, d.h., regelmäßig in Software nachschauen, ob das Signal bei logisch 0 oder 1 ist, aber der Optimist in mir hofft, dass so ein Unsinn bei aktuellen Handys nicht mehr gemacht wird.

Es gibt auch hybride Strategien wo Polling garnicht mal so boese ist. Dort werden z. B. nach einem Tastenevent fuer die Dauer der Entprellzeit weitere Interrupts maskiert und in bzw nach dieser Zeit wird gepollt. Hierdurch kann man sich vor vielen Prellsignalen schuetzen. Diese Loesung funktioniert aber natuerlich nicht bei zufaellig und jederzeit eingebrachte Stoerungen wie sie beim GN auftreten.
Tobias

 

[NilaT]

Ui, Spekulationen auf höherem Niveau... *i like*
Aber im Endeffekt bleibt es bei "ich glaube", weil eben niemand anderer als Samsung und Google genau weiß, was los ist... Falls die es überhaupt wissen
Im Endeffekt wird es aber sowieso jedem egal sein, solange es funktioniert, wird das Gerät gekauft werden.

 

[sungazer]

Hallo Tobias,

Hi Sungazer, ist wohl nicht so schlimm, weil das Entprellen bzw. das Eventhandling in einem fPGA sitzt und nur echte Events an die CPU gemeldet werden.

Wo kommt die Info mit dem FPGA her? FPGAs (Field-Programmable Gate Arrays) erlauben es Logik in Software zu definieren. Im Prinzip lädt man eine Binärdatei auf das FPGA und dann werden je nach 0 oder 1 darin "Schalter" in großen Rastern auf dem FPGA geöffnet oder geschlossen. Dazwischen hängen Transistoren oder größere Logikblöcke, die man so relativ frei zusammenschalten kann. Ziemlich coole Sache, für Consumer-Hardware aber viel zu teuer.

Die beschriebene "Entprellen durch Warten in Hardware" Funktionalität ist im übrigen auf dem OMAP 4460, der im Galaxy Nexus stecken soll, auf dem Chip schon vorhanden. Wen das interessiert, die Doku ist online (nach "debounc" suchen): http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.0_PUBLIC_TRM_vF.zip

Und, ja, die Indizien sprechen dafür, dass der "Fix" die Werte anpasst, die in die GPIO_DEBOUNCINGTIME Register geschrieben werden. Ohne aber den genauen Patch gesehen zu haben kann ich das nicht endgültig sagen.

Den Patch zu sehen, fände ich übrigens interessant, falls da jemand einen Link hat (als diff; dafür, die Info aus den kursierenden Images mit angewandtem Patch zu extrahieren, reicht meine Motivation dann doch nicht ).

Es gibt auch hybride Strategien wo Polling garnicht mal so boese ist. Dort werden z. B. nach einem Tastenevent fuer die Dauer der Entprellzeit weitere Interrupts maskiert und in bzw nach dieser Zeit wird gepollt. Hierdurch kann man sich vor vielen Prellsignalen schuetzen. Diese Loesung funktioniert aber natuerlich nicht bei zufaellig und jederzeit eingebrachte Stoerungen wie sie beim GN auftreten.

Danke für die Ergänzung. Das hat zwar mit Polling, so wie ich es kenne, nichts zu tun, ist aber eine mögliche Strategie, unnötige Interrupts zu vermeiden. In der Praxis scheitert es häufig daran, dass mehrere Events sich einen Interrupt teilen und man die Events nicht einzeln maskieren kann.

--sg

 

[toschel]

Wo kommt die Info mit dem FPGA her?

Hier im Thread, Betrag 275 ist ein Zitat und ein Link wo der Fix diskutiert wird unter anderem auch die Frage, ob Eventlistener nicht eine hohe CPU-Last verursachen.

 

[sungazer]

Hier im Thread, Betrag 275 ist ein Zitat und ein Link wo der Fix diskutiert wird unter anderem auch die Frage, ob Eventlistener nicht eine hohe CPU-Last verursachen.

Ich sehe da keine Erwähnung von FPGA. Ansonsten deckt es sich mit der Funktion der GPIO_DEBOUNCINGTIME Register. Wenn da von "fixed the problem in software" die Rede ist, ist schlicht ein "schreibe 1234 statt 5678 in Register soundso" gemeint. Das führt der Bootloader einmal aus und dann vergleicht die fest im Chip verdrahtete Hardware bei eingehenden Signalen einen Timer-Wert mit der Zahl aus dem Register (und das frisst in der Tat keine CPU-Zeit, falls mich da jemand missverstanden hat).

--sg