> Я так и написал - это только декодирование mp3 + затраты на
> чтение. Статику я отбросил, она одинакова для обоих случаев и зависит от soc и софта.Как вы сами же и померяли в вашем же смарте - нечто типа статичного потребления и прочего может оказаться доминирующим. А вы его отбрасывать? ИМХО так не годится, попахивает систематической ошибкой измерений. Для аппаратных плееров наверное может быть ближе к тому что вы описали. Но опять же это зависит от конкретики управления питанием, в том числе, кроме системного проца еще и всяких чипов памяти, встроенного контроллера sd карты и кто там еще.
> Там большой буфер. В него читается из flash и затем flash отключается.
А вот кто и как читал флеш, какой там буфер, какие таймауты, насколько больше/меньше RAM потребляет и проч - какой-то отдельный вопрос. И поэтому идея отмасштабировать все банальным делением кажется мне неудачной. Это может прокатить плюс-минус 2 раза, но не в десятки.
Вот так из жизни, приколы low power: если N900 воткнуть на заряд, можно порулить charge manager-ом. Кроме всего прочего народ сделал скриптики позволяющие выбирать зарядный ток из нескольких вариантов которые чип умеет. Можно лопать максимум, как от wall charger, можно лимитировать до 800, 500 или 100 ма.
Прикол оверхеда: система, заметив зарядник, перестает агрессивно экономить. Парадокс, но током 100mA n900 невозможно зарядить. Активизировавшаяся система лопает ... больше. И заряд оказыавется неторопливым разрядом. Так что в полевых условиях зарядиться от 4 солевых батареек - не катит. Хотя алкалин 500мА тянет долго. А вот дефолтный "безлимит" вырубает алкалин за 10 минут, у них проваливается напряжение. Чип срубает заряд по undervoltage lockout. FAIL.
> А трескает проц, который декодирует и отсылает данные.
Это может быть верно для какого-то конкретного плеера, и то - я в такие вещи не поверю аппроксимированным делением, для нормальных выводов требуется замер фактического потребления системы. Мультиметр потребление цифровой системы с сильными короткими burst нормально мерять не обязан, кстати. Апериодический импульсный процесс. Там надо какое-то интегрирование делать. Кондеры на входе питания может это немного и сделают, но нынче в моде керамика, там постоянная времени и величина burst-ов наверное вполне может сглючить мультиметр. Измерение шустрых импульсных процессов - занятие веселое. И даже хардварные charge gauge ... ну вот у n900 gauge полагает что старая 1200mA*h батарейка дает 1900ma*h. Я со своей стороны считаю что charge gauge просто сдурел от округлений и погрешностей, когда девайс лежал недельку кушая свои 4 ма. И запомнил как емкость какой-то фэйспалм. Это явно ошибочное измерение. Не может древняя 1200 ма*h батарейка так разогнаться.
> Так или иначе все это я отбросил, так как нас интересовало -
> что затратнее i/o или декодирование.
Лично меня скорее интересует практический сценарий. А именно: есть некая система. Она играет те или иные форматы. Для пользователя интересно сколько оно проживет с неким форматом, чтобы понимать tradeoff-ы между размерами и временем звучания. Наиболее честный и очевидный способ - зарядить, закольцевать, померять через сколько срубится, и так для разных форматов. Вопрос с интегрированием импульсных процессов и оверхедом - решится сам, в виде максимально приближенном к реальности. Но это долго и не сказать что удобно. Зато сразу готовый ответ - во что на практике различие форматов отливается. А то что мы отбросили одно и оставили другое - ну хорошо, допустим, а какую практическую ценность это несет? Пользователь в конце концов получит на свою голову систему целиком, со ВСЕМ тамошним оверхедом и особенностями.
