News Helio X20: 10-Core-SoC von MediaTek hat einen MP3-Koprozessor

nlr

Redakteur
Teammitglied
Registriert
Sep. 2005
Beiträge
9.982
Aufnahmen von Präsentationsfolien des MediaTek Helio X20 mit Tri-Cluster-Design kursieren seit mehreren Tagen durchs Netz, zur heute offiziell erfolgten Vorstellung des 10-Core-SoC gibt es weitere Details zum intern MT6797 genannten Chip. Hierzu zählt ein Koprozessor, der unter anderem für die Wiedergabe von MP3 optimiert wurde.

Zur News: Helio X20: 10-Core-SoC von MediaTek hat einen MP3-Koprozessor
 
Bei "dauerhaft aktivierten Google Spracherkennung" hat's bei mir ausgesetzt... :p
 
Demnächst dann der neue 35 Kerner. Mit MP3 Koprozessor und MP4 Koprozessor und Whatsapp Koprozessor und Schnitzel Koprozessor und Koprozessor für die Koprozessoren. :freaky:

Naja wird schon alles seine Daseinsberechtigung haben.
 
Für ein Smartphone völliger Schwachsinn.
Für einen Mediaplayer wäre das aber was.
H.265 kann soweit ich weiss noch keiner.
4K@30Hz reicht bei nicht HDMI2.0 auch noch.
MP3-Koprozessor wäre für einen Mediaplayer auch brauchbar.
Auf das LTE könnte man dabei natürlich verzichten . .


Man muss nicht immer sofort meckern, nur weil man nicht alle Einsatzgebiete bedenkt . .
 
Zuletzt bearbeitet:
Schwachsinn ist das nicht, das Nexus 5 hat auch einen Coprozessor für mp3-Wiedergabe, der die Akku-Laufzeit deutlich verlängert.
 
Stahlseele schrieb:
...
Für einen Mediaplayer wäre das aber was.
H.265 kann soweit ich weiss noch keiner.
. .

Soweit ich das gelesen habe können sowohl der Snapdragon 810 sowie der Exynos 7420 H.265 (HVEC) decodieren per Hardware.

Ansonsten wirken diese Konstrukte immer leicht seltsam, da stellt sich die Frage ob es sich wirklich lohnt oder die damit quasi nur ne Nullrunde laufen, was den Energiebedarf anbelangt, es aber für das Marketting besser ist.
 
Ich meinte Mediaplayer. Da gibt es bisher noch keinen mit Hardware-Support für H.265 soweit ich weiss.
Aber danke, bei den anderen SOCs wusste ich das bisher auch noch nicht.
 
@Stahlseele

Auch der AmLogic S812 hat laut Datenblatt einen Decoder für H265 und UHD an Board.
Und das ist ein Billiger China SoC der in vielen Android TV Boxen zu finden ist.
 
Also tri-Cluster sind schon sowas von out. Quad Cluster mit bis zu 20 kernen bringen den Durchbruch in Sachen Leistung und Akku Laufzeit. Jede App hat dann seinen eigenen Kern.
Da frag ich mich echt wie man heut zu Tage noch mit einem Dual Core rumlaufen kann. Ein Wunder dass man damit überhaupt telefonieren kann ohne dass der Ton ins Stocken gerät. /Ironie
 
Zuletzt bearbeitet:
Ein Coprozessor für MP3-Wiedergabe? Liest sich für mich so, als hätte der SoC weniger Leistung als ein 486 DX2*-66 (der hatte genug Leistung für MP3-Wiedergabe inklusive Win95 im "Hintergrund"). :D

*) Die "2" hinter dem "DX" steht nicht für Dualcore, muss heutzutage immerhin erwähnt werden.

Edit:
Wolfsrabe schrieb:
Bei "dauerhaft aktivierten Google Spracherkennung" hat's bei mir ausgesetzt... :p
Die Fressebuch-App verlangt sogar die Berechtigung zur Tonaufzeichnung. Man trägt also das "persönliche Echelon" (Fressebuch arbeitet immerhin mit dem Betreiber des Echelon-Systems zuammen) mit sich rum, wenn die App installiert ist und das Handy online ist. :evillol:
 
Zuletzt bearbeitet:
Vindoriel schrieb:
Ein Coprozessor für MP3-Wiedergabe? Liest sich für mich so, als hätte der SoC weniger Leistung als ein 486 DX2*-66 (der hatte genug Leistung für MP3-Wiedergabe inklusive Win95 im "Hintergrund"). :D

Naja... Bei 44,1khz + 128kbit/s +vl noch Stereo hatte der schon arge Schwierigkeiten, 22,5khz auf mono-betrieb ging dann halbwegs :D
 
Was ist denn das akkuschonendste Format fürs Smartphone (habe aktuell ein N4), wenn kein MP3-Kompressor mit dabei ist? *.ogg, *.m4a, *.wav? :D

Kenne mich damit wenig aus. Konvertiere meine Musik aus Gewohnheit immer in *.mp3 (196kbit/s) und habe mir über den Verbrauch nie Gedanken gemacht. Aber Musik hören lutscht beim N4 durchaus gut am ohnehin schon schwachen Akku.

Von welchen Differenzen sprechen wir da überhaupt zwischen den Formaten? Wenn selbst ein extra MP3-Kompressor "nur" 30% Ersparnis bei Wiedergabe bringen soll..
 
Zuletzt bearbeitet: (Wort vergessen..)
Nimm Wave :D. Das ist unkomprimiert, da muss der Prozessor quasi gar nichts machen außer Daten von A nach B schaufeln. Leider ist ein Lied dann gerne 50MB groß.
Trotzdem denke ich, dein Display ist trotz MP3-decodierung immer noch der Hauptverbraucher, gefolgt von der Datenpeitsche. Die Kopfhörer wollen auch versorgt werden. Das bisschen mp3 decodieren tut dabei nicht viel zur Sache beitragen, also ist auch das Format an sich egal.
 
Zuletzt bearbeitet:
Vindoriel schrieb:
Ein Coprozessor für MP3-Wiedergabe? Liest sich für mich so, als hätte der SoC weniger Leistung als ein 486 DX2*-66 ...

Es geht hierbei nicht darum, dass der SoC nicht die Leistung hätte, MP3 vernünftig zu dekodieren, sondern vielmehr darum, die Hauptkerne weitestgehend abschalten zu können, wenn beispielsweise das Display aus ist und nur Musik wiedergegeben wird. Und für diesen Zweck reicht so ein Mini-Coprozessor locker aus. Gleiches gilt auch für die Verarbeitung der Sensorinformationen.
 
Ist der Ko-Prozessor eigentlich wirklich dazu da MP3 zu decodieren, oder um den Hardwarede- bzw Hardwareencodern die Daten zu liefern?

Ein Ko-Prozessor zum (Software-)Encoding zu nutzen, wenn die meisten SoCs eh schon in Hardware en-/decodieren wäre eigentlich ein Rückschritt. Eine kleine CPU zu nutzen um über diesen die Verwaltung der "primitiven" Funktionen bis hin zu Audiowiedergabe aufzuerlegen wäre hingegen eine recht brauchbare Idee. Dann müssten die großen CPU Kerne nicht mehr aufwachen, um die Hardwarecodecs mit Daten zu füttern.

@ghecko
Das encodieren von MP3 ist nicht so aufwendig. Mitunter ist es durchaus so, dass größere, lesende Zugriffe auf Dateisysteme samt fälliger interner Kopiervorgänge energetisch schlechter gestellt sind, als das Einlesen und verarbeiten komprimierter Daten. Pauschal, kann man da mittlerweile kaum mehr Aussagen treffen.
 
Piktogramm schrieb:
Ist der Ko-Prozessor eigentlich wirklich dazu da MP3 zu decodieren, oder um den Hardwarede- bzw Hardwareencodern die Daten zu liefern?
Ein Cortex M4 ist auch nichts anderes als ein "normaler" CPU, der allerdings extrem wenig verbraucht und wie angegeben sehr gering taktet. Deswegen wird er halt nur mit Aufgaben betraut die halt nach wenig Leistung verlangen. Wenn also eine Anwendung MP3 abspielt können tatsächlich alle anderen Kerne schlafen gelegt werden und der sparsame M4 übernimmt diese Aufgabe. Wie Mediakthek schon sagt ist die CPU so aufgebaut, dass sie in jedem Anwendungsszenario möglichst wenig Energie verbraucht. Es hat weniger damit zu tun, dass hier extreme Leistung erbracht wird, sondern das jede Aufgabe effizient abgearbeitet wird. Deshalb verbaut auch Samsung seinen OcatCore in Uhren, weil er halt extrem sparsam arbeiten kann.

Ob es allerdings Sinn macht zwei A53 Clust mit unterschiedlichem Takt zu verbauen oder liebe reinen dynamisch takteten der bei Bedarf durch A72 unterstützt wird sei aber mal dahin gestellt. 4xA53 + 2x72 oder gar 4xA53 + 4xA72 hätten es sicherlich auch getan.
 
@GrooveXT

Du hast meinen Post nicht verstanden :)

Normalerweise haben moderne SoC für den Mobilbereich sowieso Hardwarede- und -encoder für gängige Audioformate. Diese Hardwarelösung ist eigentlich immer sparsammer als jede Softwareimplementierung, egal wie gut optimiert die CPU ist. Insofern frage ich mich, ob der sehr kleine CPU Kern wirklich Software encodiert, oder (was ich für eleganter halte) nur Verwaltungsaufgaben während der MP3 Wiedergabe übernimmt und das Processing in den Hardwareeinheiten stattfindet.
Das Letzte wäre wirklich ein richtiges technisches Schmankerl.
 
Zurück
Oben