форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от opennews (ok) on 10-Ноя-16, 23:21
Кристиан Шаллер (Christian Schaller), возглавляющий группу по развитию десктоп-систем в компании Red Hat и Fedora Desktop Team, сообщил (https://blogs.gnome.org/uraeus/2016/11/10/mp3-support-now-co.../) о реализации встроенной поддержки декодирования формата MP3 в Fedora Workstation 25. Поддержка кодека MP3 обеспечена через функцию загрузки плагина в интерфейсе GNOME Software и через установщик  недостающих кодеков, интегрированный в различные приложения на базе GStreamer. Поддержка реализована через библиотеку mpeg123 и соответствующий плагин  GStreamer. Не исключается, что в Fedora Workstation 26 компоненты для поддержки MP3 будут включены в основной установочный образ. Напомним, что в Fedora 24 была добавлена (https://www.opennet.dev/opennews/art.shtml?num=44426) поддержка видеокодека H.264, реализованная через включение в репозиторий пакета с метаданными при фактической загрузке кодека openh264 с сайта Cisco. URL: https://blogs.gnome.org/uraeus/2016/11/10/mp3-support-now-co.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=45473
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "В Fedora добавлена встроенная поддержка MP3"	+7 +/–
Сообщение от KOT040188 (ok) on 10-Ноя-16, 23:21
В kde всегда так можно было подгрузить. Но я всегда устанавливал кодеки на этапе установки системы. И да, mp3 должен умереть! Да здравствует ogg!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "В Fedora добавлена встроенная поддержка MP3"	+2 +/–
	Сообщение от Аноним (??) on 10-Ноя-16, 23:40
	Полностью согласен, хоть сейчас! Кстати, напомни, какие хардварные аудиоплееры умеют ogg?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 10-Ноя-16, 23:53
	> Кстати, напомни, какие хардварные аудиоплееры умеют ogg? все, на которые ставится rockbox SanDisk Clip Sport многие AGPTEK/RUIZU многие другие китайцы
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	37. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от ShpurloS on 11-Ноя-16, 08:14
	Аж прослезился от умиления, вспомнил свой Cowon x5 )) Оно еще шевелится там?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	47. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 11:51
	> Оно еще шевелится там? Шевелится, неспешно готовимся к релизу. Очень неспешно, второй год :) Но изменений хватает: https://www.rockbox.org/wiki/MajorChanges Основная сейчас сложность - проблема купить плеер, на который можно поставить rockbox (старые сняли с производства, а новые деградировали - RAM < 1MB).
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	43. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от username (??) on 11-Ноя-16, 10:45
	Не обязательно rockbox, купил в бородатых годах некий ritmix, неожиданно но ogg там была поддержка, как и возможность установить rockbox.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	48. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 11:54
	> Не обязательно rockbox, купил в бородатых годах некий ritmix, неожиданно но ogg > там была поддержка, как и возможность установить rockbox. Так я и говорю - многие другие китайцы. Rockbox ставится на фирменные плееры (cowon/ipod/iriver/sansa/etc).
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	22. "В Fedora добавлена встроенная поддержка MP3"	–6 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 01:41
	А что такое "хардварные аудиоплееры"? Ну айпод знаю… Помню был у меня когда-то касетный магнитофон…
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	29. "В Fedora добавлена встроенная поддержка MP3"	+3 +/–
	Сообщение от Линукс еще не готов on 11-Ноя-16, 03:19
	Магнитолка в автомобиле, например.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	59. "В Fedora добавлена встроенная поддержка MP3"	–2 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 15:17
	Мне врачи не разрешают за руль к сожалению…
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	69. "В Fedora добавлена встроенная поддержка MP3"	–10 +/–
	Сообщение от commiethebeastie (ok) on 11-Ноя-16, 17:26
	И действительно, дорасти до 18 лет и не знать что такое взятка.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	93. "В Fedora добавлена встроенная поддержка MP3"	+4 +/–
	Сообщение от KOT040188 (ok) on 12-Ноя-16, 03:11
	Вы наверное не в курсе, но кроме взяток в мире существует  ещё и здравый смысл. Не просто так они меня не пускают. Я не хочу рисковать чужими жизнями.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	97. "В Fedora добавлена встроенная поддержка MP3"	–3 +/–
	Сообщение от Линукс еще не готов on 12-Ноя-16, 09:01
	Психические отклонения чтоли
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	99. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 16:33
	Причин может быть множество.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	100. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 18:27
	> Психические отклонения чтоли Может он сознание теряет внезапно? Хочешь чтобы в тебя въехал на скорости 100 неуправляемый пепелац? Просто потому что водилу вырубило и он отвалился, зажав тапок в пол.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	115. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 13-Ноя-16, 16:15
	Да. Я кидаюсь в припадке на тех людей, кто пишет "Линукс ещё не готов" %)
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	36. "В Fedora добавлена встроенная поддержка MP3"	+3 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 06:57
	Стыд и позор не знать этого. Выросло, поколение...
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	49. "В Fedora добавлена встроенная поддержка MP3"	+7 +/–
	Сообщение от анонимус (??) on 11-Ноя-16, 11:56
	Эх, молодёжь. Хардварный плеер - это патефон.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	60. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 15:17
	Согласен. Но при чём здесь mp3?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	68. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от анонимус (??) on 11-Ноя-16, 15:57
	Не знаю. Вопрос был про хардварь. Софтварь - это к программистам.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	50. "В Fedora добавлена встроенная поддержка MP3"	+6 +/–
	Сообщение от Sound Master on 11-Ноя-16, 12:11
	Дорогой школьник. Хардварные плееры это Cowon, iRiver, Sony Walkman, HiFiMan и прочие. Очень странно в наши дни слышать такой вопрос. Как-будто есть другой способ иметь высокое качество звука в кармане. Тем кому в детстве медведь ухо откусил, конечно подойдет и встроенный плеер айфона/сосунга с дефалтными затычками, но тем кому нужен нормальный звук, только хардварные плееры.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	53. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 12:39
	А чем тебе не нравится штатный 24-битный ЦАП и штатные сертифицированные Hi-Res Audio наушники современного смартфона?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	55. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 13:52
	> А чем тебе не нравится штатный 24-битный ЦАП и штатные сертифицированные Hi-Res > Audio наушники современного смартфона? Со смартфонами все не так однозначно, ищите замеры и желательно под нагрузкой эквивалентной вашим наушникам. К примеру Nexus S очень сильно проигрывает плееру примиренно того же года выпуска - Clip Zip (ценой 30-40$). http://forums.rockbox.org/index.php/topic,51468.msg237935.ht... Есть китайский сайт с замерами (http://www.soomal.com/doc/10100003507.htm), но там замеры без нагрузки, что не очень информативно. Но даже на нем видно, что многие телефоны имеют проблемы - без нагрузки искажения (THD/IMD) должны быть менее 0.01%.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	62. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 15:20
	Китайские замеры… Для них нужны китайские уши…
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	73. "В Fedora добавлена встроенная поддержка MP3"	–2 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 17:32
	> Китайские замеры… Для них нужны китайские уши… Сделаны русской rmaa ;) Да и они вполне согласуются с отдельными замерами различных людей. Но как я уже сказал - они без нагрузки, под нагрузкой все будет гораздо печальнее. Вот другой сайт: http://en.goldenears.net/GR_Mobile Замеров там меньше, но авторитет сайта не вызывает сомнений.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	77. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 18:50
	> Сделаны русской rmaa ;) Угу, проприетарной. Поверим на слово результатам непроверяемых замеров обрабатываемых хзкак. Сразу после того как лицензию на новый винрар купим.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	88. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 01:38
	> Угу, проприетарной. Поверим на слово результатам непроверяемых замеров обрабатываемых > хзкак. Лет десять назад я общался с автором rmaa. Я сказал, что хочу сделать порт под linux и попросил исходники. Он ответил, что может открыть измерительную часть программы и выслал мне ее исходники. Я был тогда почти не знаком с DSP и ушло некоторое время, пока я почитал книги и понял, что к чему. Разобрался, какие алгоритмы использует он и какие еще можно добавить. В итоге собрал консольную версию и начал работать над UI. Но до состояния, что бы выложить так и не довел. Тогда, я не уточнил под какой лицензией я могу опубликовать его код. Так что не буду сейчас его выкладывать - если есть конкретные вопросы, то могу сказать что там и как сделано. В целом же все достаточно стандартно. И ничего крамольного там нет.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	101. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 18:34
	> Тогда, я не уточнил под какой лицензией я могу опубликовать его код. > Так что не буду сейчас его выкладывать - если есть конкретные > вопросы, то могу сказать что там и как сделано. Просто с закрытыми исходниками - ценность измерений равна нулю. Проприетарный софт - это издевательство над идеей эксперимента и продвижение антинаучных подходов. Результат непроверяем - о чем можно говорить? И вообще, говоря за себя - продвижение антинаучных подходов и проприетарных форматов, особено на ресурсе по открытому ПО имхо подмачивает уважение к вам как специалисту. > В целом же все достаточно стандартно. И ничего крамольного там нет. Да я понимаю что джентльменам верят на слово, поэтому Петьке карта и прет.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	105. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 19:47
	> Просто с закрытыми исходниками - ценность измерений равна нулю. Слишком смелое заявление. У вас есть прошивки для тестера/осциллографа/etc? Есть приборы и есть стандарты измерений. Если прибор соответствует стандартам, то все равно, что там внутри. > Проприетарный софт - > это издевательство над идеей эксперимента и продвижение антинаучных подходов. Результат > непроверяем - о чем можно говорить? Почему не повторяем? Все аналогичные программы используют сходные алгоритмы и результаты очень близки. > И вообще, говоря за себя - продвижение антинаучных подходов и проприетарных форматов, > особено на ресурсе по открытому ПО имхо подмачивает уважение к вам > как специалисту. Вы о том, что я имею наглость заявлять, что у закрытых программ тоже есть интересные идеи и что надо дорабатывать и развивать СПО, дабы оно не уступало закрытым аналогам? Конечно, лучше спрятать голову в песок и кричать, что СПО идеально, а все остальное антинаучно и вообще гумно. А потом удивляться, чего у десктопа linux 1%? >> В целом же все достаточно стандартно. И ничего крамольного там нет. > Да я понимаю что джентльменам верят на слово, поэтому Петьке карта и > прет. Хватит демагогии. Что по вашему в rmaa может быть не так? Вы хотя бы общее представление имеете о подобных замерах? Все это разжевано в букварях по DSP и замерам искажений. rmaa просто одна из реализаций. Если есть конкретные вопросы - могу посмотреть и ответить. Забыл самое главное: раз уж вы так хорошо разбираетесь в научных подходах - проведите свои измерения (можете заодно и свой софт написать и выложить), раз уж вас так не устраивают чужие замеры и программы.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	113. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 13-Ноя-16, 05:17
	> Слишком смелое заявление. Да вроде обычное - это дефолтное состояние дел для измерений. Если кто-то считает что его измерения валидны - пусть обоснует почему он так считает. > У вас есть прошивки для тестера/осциллографа/etc? А это достаточно интересный вопрос. Во первых, не вижу что помешает вместо хзкакого мультиметра/осцила ухватить пачку отсчетов ADC, понимая всю цепочку погрешностей и что в результате намеряно. Во вторых для нормальных приборов указываются погрешности и методики поверки и период валидности. Если прибор достаточно характеризован и предоставлены методики поверки - ок, тогда можно и без сорца. Но в случае цифровых приборов с фирмварой и софта есть основания трижды перепроверять. По понятным причинам - нелинейная/условная логика потенциально может выдать что угодно если захочет. > Если прибор соответствует стандартам, то все равно, что там внутри. Ну ладно, тогда: 1) Каким стандартам соответствует RMAA+оборудование на котором делались замеры? 2) Кто это соответствие проверял? 3) Какая методика проверки соответствия этой комбинации стандартам из 1)? Ну так, глядя на хотя-бы инструкцию по мультиметру, где подробно описано какие погрешности, как проверить что они остались именно такими и как часто это надо делать. Так мне понятно как отличать прибор от показометра и какие параметры от прибора ожидаются. > Почему не повторяем? Все аналогичные программы используют сходные алгоритмы > и результаты очень близки. Кто-то машет какими-то цифрами которые "выдала программа". Я в ответ интересуюсь - почему это считается чем либо кроме набора циферок? Ученые и инженеры не доверяют циферкам по умолчанию. > тоже есть интересные идеи и что надо дорабатывать и развивать СПО, > дабы оно не уступало закрытым аналогам? Я не спорю что в закрытых программах могут быть интересные решения. Но вот конкретно тут проблема в обосновании валидности результатов. Для моего мультиметра я знаю что там не "эн вольт", а "эн вольт плюс-минус столько-то". Как оценить плюс-минус сколько. И как проверить что это и правда вот так. Приборы умеют врать. Это заставляет по умолчанию не доверять результатам. > Конечно, лучше спрятать голову в песок и кричать, что СПО идеально, СПО не идеально. Но в данном случае - проблема скорее в том что кто-то получил из какого-то черного ящика какой-то результат и почему-то настаивает что он валиден. А обоснований причин валидности я не вижу. > Хватит демагогии. Что по вашему в rmaa может быть не так? Вы > хотя бы общее представление имеете о подобных замерах? Для начала я имею представление о проведении измерений и погрешностях. Этого достаточно чтобы задать мои вопросы. И попытки взять на п0нт совершенно не прибавят доверия к группе циферок выданных на гора "какой-то программой". > Все это разжевано в букварях по DSP и замерам искажений. Не очень убедительное обоснование валидности результатов, имхо. > rmaa просто одна из реализаций. Это не обязывает меня взять под козырек и слепо доверять выхлопу этой штуки. > Если есть конкретные вопросы - могу посмотреть и ответить. Ну тогда: 1) Каковы погрешности ваших измерений с научной точки зрения и почему именно столько? 2) Искажения без нагрузки - какой в них смысл? Это же невозможно услышать?! 3) Надеюсь что вы знаете что такое "комплексное сопротивление цепи", если меряете сотые доли THD "без нагрузки". И если уж не оцените его, то как минимум подтвердите что комплексное сопротивление было хоть приблизительно одинаковым в обоих замерах? 4) А под нагрузкой - почему нагрузка разная? Почему нельзя было использовать одинаковую? 5) То что у самсуня динамический диапазон оказался заметно шире вас не смутило? (хотя опять же, нагрузка разная) 6) Неплохо бы обоснование валидности вашей экстраполяций. Какие к тому предпосылки на уровне физики и схемотехники? > Забыл самое главное: раз уж вы так хорошо разбираетесь в научных подходах > - проведите свои измерения (можете заодно и свой софт написать и > выложить), раз уж вас так не устраивают чужие замеры и программы. ИМХО кто результаты выложил - тот и обосновывает почему они по его мнению валидны. А так то я тоже могу запустить каку-то прогу и скопипастить какие-то цифры. Я даже могу цифры с потолка написать. Будет ничем не хуже по обоснованию. А если не нравится - тогда вы и перемеряйте, так? Ваша логика ведет куда-то туда. Только это какой-то хреновый и антинаучный подход к измерениям, когда свойства сущностей объективно установить вообще не получится.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	118. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 14-Ноя-16, 02:47
	>> У вас есть прошивки для тестера/осциллографа/etc? > А это достаточно интересный вопрос. Во первых, не вижу что помешает вместо > хзкакого мультиметра/осцила ухватить пачку отсчетов ADC, понимая всю цепочку погрешностей > и что в результате намеряно. Все проще - берется эталон и проверяется прибор на погрешности. > Но в случае цифровых приборов с фирмварой и софта есть основания > трижды перепроверять. По понятным причинам - нелинейная/условная логика потенциально > может выдать что угодно если захочет. Сейчас практически все приборы на uC или SoC. Все выкинуть? Я конечно и сам до сих пор использую М2020 (индивидуальный аттестат в наличии) в качестве эталона, но в быту вполне обхожусь цифровыми приборами. >> Если прибор соответствует стандартам, то все равно, что там внутри. > Ну ладно, тогда: > 1) Каким стандартам соответствует RMAA+оборудование на котором делались замеры? RMAA сама сейчас стандарт :) На самом деле появление RMAA очень сильно повлияло на индустрию - у пользователей появилась возможность самим проверить заявленное количество нулей в THD. RMAA это чистая математика. Стандарте алгоритмы измерения (THD/IMD) едины для всех - FFT он и в Африке FFT. Основная разница между подобным софтом/приборами - алгоритмы усреднения и размер окна FFT. Точность - 144dB (или больше, не помню), фактически ограничивается погрешностью аудио формата. Оборудование - у кого какое есть. Я лично пользуюсь emu-1212m и emu-0204. > 2) Кто это соответствие проверял? Все кому не лень. Были и сравнения с профессиональным программно-аппаратным комплексом, которым часто производители пользуются. Проводились тысячи (если не миллионы) замеров - практически всегда результаты близки к заявленным производителем, за исключением откровенного жульничества производителей. > 3) Какая методика проверки соответствия этой комбинации стандартам из 1)? Математический аппарат вы можете легко проверить генерируя искусственные искажения. Железо - datashet на dac/adc + заявленные характеристики производителя звуковой платы. > Ну так, глядя на хотя-бы инструкцию по мультиметру, где подробно описано какие > погрешности, как проверить что они остались именно такими и как часто > это надо делать. Так мне понятно как отличать прибор от показометра > и какие параметры от прибора ожидаются. Для этого нужен эталон/несколько приборов. > Для моего мультиметра я знаю что там не "эн вольт", а "эн > вольт плюс-минус столько-то". Как оценить плюс-минус сколько. И как проверить что > это и правда вот так. Приборы умеют врать. Это заставляет по > умолчанию не доверять результатам. Звуковую плату можно проверить замкнув выход на вход. Увидим ее собственные погрешности. > Ну тогда: > 1) Каковы погрешности ваших измерений с научной точки зрения и почему именно > столько? Конкретно мои для clip zip были сделаны на emu-0204. Можете глянуть уровень ее искажений. Он существенно ниже clip zip или любого телефона. > 2) Искажения без нагрузки - какой в них смысл? Это же невозможно > услышать?! Это условно называется  без нагрузки. Нагрузкой выступает звуковая плата, я обычно еще 10K вешаю, дабы меньше помех ловить. Смысл следующий: мы видим потолок, на который способно устройство. Это полезно при подключении к внешнему усилителю или высокоомным наушникам. > 4) А под нагрузкой - почему нагрузка разная? Почему нельзя было использовать > одинаковую? Я использую 22 ома, так как лениво отдельно мерить каждый раз 16 и 32 ома. Соответственно и результат средний. Самсунга у меня нет, замеры чужие. > 5) То что у самсуня динамический диапазон оказался заметно шире вас не > смутило? (хотя опять же, нагрузка разная) Разница в 3dB под нагрузкой и 0dB без? Ее можно списать на погрешность измерений. Если бы разница была в 6-10dB (2-3 раза как для искажений) - тогда был бы повод задуматься. > 6) Неплохо бы обоснование валидности вашей экстраполяций. Какие к тому предпосылки на > уровне физики и схемотехники? Из опыта построения усилителей. Я уже много лет занимаюсь аудио. И программу для замеров всего и все потихоньку пишу - будет достойный свободный конкурент rmaa и не только. Основная проблема ОУ - ток. Чем ниже сопротивление нагрузки, тем сильнее искажения. Зависимость конечно не линейная и зависит от конкретного ОУ, но в первом приближении (если речь идет об разницы в разы, а не о единицах процентов) можно считать ее таковой. > ИМХО кто результаты выложил - тот и обосновывает почему они по его > мнению валидны. А так то я тоже могу запустить каку-то прогу > и скопипастить какие-то цифры. Если эта программа используется во всем мире многими авторитетами и изданиями в данной области - почему нет? > А если не нравится - > тогда вы и перемеряйте, так? Ваша логика ведет куда-то туда. Только > это какой-то хреновый и антинаучный подход к измерениям, когда свойства сущностей > объективно установить вообще не получится. Что действительно антинаучно, так это спорить с анонимном о науке ;) Если серьезно - то это единственный и постоянно практикуемый научный способ. Когда кто-то заявляет, что сделал открытие идущие в разрез с ожидаемым результатом - все ждут повторного проведения эксперимента другой группой, так как это единственный способ исключить подлог или некорректную постановку эксперимента. Вся наука строится на постоянной перепроверке, в том числе и, казалось бы, незыблемых истин. Ничто не убеждает так, как повторенный собственными руками эксперимент.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	72. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 17:31
	Т.е. по-твоему все дело в наушниках, да? А гaвноначинка в мобильниках это дело десятое?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	102. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 12-Ноя-16, 18:42
	> Т.е. по-твоему все дело в наушниках, да? А гaвноначинка в мобильниках это > дело десятое? Дефолтные затычки настолько плохи, что до плохости начинки не дойдет. Все мелкие наушники крайне компромиссны. И слушать без слез можно только самые крутые и дорогие из них, и то - со скрипом. А постоянно носить "колонки на ушах" сколь-нибудь близкие к мониторным - это все-таки это сильно не для всех. К тому же если ты на улице используешь совсем закрытые наушники - ты заметишь истошно сигналивший камаз лишь когда он тебя переедет. А в открытых ты будешь слышать много внешнего шума и не то чтобы тебе качество будет очень принципиально.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	61. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 15:19
	Дорогой нешкольник, вы плохо определяете возраст по сообщениям. Настоятельно рекомендую перестать это делать.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	71. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 17:30
	Вы говорите глупости, подобно школьнику. Вот я и сделал вывод, что вы школьник. Очень хотел бы извиниться, если не угадал.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	78. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 19:16
	Глупости — это радоваться этой новости.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	80. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 19:25
	А кто радуется? Мне пофиг на мп3.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	74. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Анончик on 11-Ноя-16, 17:42
	Надо же. Вообще конечно, правильности никакой в такой терминологии нет. Плеер и смартфон устроены одинаково (аппаратная часть и ПО - оно ведь в "хардварном" плеере тоже есть), ну аппаратная часть отвечающая за звук в "хардварном" плеере лучше.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	122. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 14-Ноя-16, 15:05
	>Тем кому в детстве медведь ухо откусил, конечно подойдет и встроенный плеер айфона/сосунга А тем кому медведь еще голову не отбил, подойдет и встроенный ЦАП современного смартфона уровня Wolfson.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	123. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 14-Ноя-16, 17:23
	Те, кому медведь ничего не отбил, должны знать, что Wolfson, это не только высококачественные ЦАП, но и ширпотреб: http://www.cirrus.com/en/products/pro/areas/PA65.html Одни WM8956/WM8521 с THD -84/-81 чего стоят. Для примера - действительно хороший ЦАП CS4398 имеет THD -107, разница в 23-26 dB, то есть более чем в десять раз.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	33. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от soarin (ok) on 11-Ноя-16, 04:58
	> напомни, какие хардварные аудиоплееры умеют ogg? Если речь о портативных, то этак 25% умеют (судя по уяндекс маркету)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	38. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от eganru on 11-Ноя-16, 09:18
	http://www.vlsi.fi/en/products/vs1005.html значительная часть кодек+цап для плееров имеет возможность разжимать кучу форматов. mp3 давно уже ужасный пережиток прошлого в котором годы как нет решительно никакой необходимости. более того - есть основание полагать, что широкое распространение mp3 ничто иное как результат преступного сговора жирующих капиталистов.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	39. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от AlexYeCu_not_logged on 11-Ноя-16, 09:55
	>Кстати, напомни, какие хардварные аудиоплееры умеют ogg? Все. Те кто не умеет — не медиаплееры.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	52. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 12:19
	Все новые, которые я видел последние 5 лет, щас сложно найти плеер без поддержки OGG.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	56. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от iPony on 11-Ноя-16, 14:52
	Нет, конечно. Легко. В Sony и Apple нет.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	54. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним84701 on 11-Ноя-16, 13:41
	> Полностью согласен, хоть сейчас! Кстати, напомни, какие хардварные аудиоплееры умеют ogg? У меня тут еще где-то валяется самсунговский YP-U1 2005 года.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	63. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 15:24
	> какие хардварные аудиоплееры умеют ogg? Этот аргумент устарел уже несколько лет как. Со времен повсеместного распространения смартфонов и слушания музыки с них. > Кстати, напомни Тут скорее надо напоминать, какие хардварные плееры всё ещё актуальны. iPod? Заменен iPhone-ом. MS Zune? Заменён виндофоном. Lee Wong Yang MP3 player? Заменён Xiaomi. И так далее.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	83. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 20:09
	Дай угадаю: телефон у тебя кнопочный "назад в нулевые" и ты не в курсе, что на смарте, дае старой нокии на симбиане,  любой формат воспроизводится?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	6. "В Fedora добавлена встроенная поддержка MP3"	+15 +/–
	Сообщение от Mihail Zenkov (ok) on 10-Ноя-16, 23:44
	> И да, mp3 должен умереть! Да здравствует ogg! У меня такое ощущение, что mp3 и jpeg проживут еще не один десяток лет. Хорошо хоть flac вовремя занял свою нишу. Теперь даже ms и apple не могут его вытеснить.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	13. "В Fedora добавлена встроенная поддержка MP3"	+3 +/–
	Сообщение от h31 (ok) on 11-Ноя-16, 00:16
	> Теперь даже ms и apple не могут его вытеснить. MS перестала бороться, в десяточке есть встроенные кодеки для FLAC и Matroska. А вот с Apple всё хуже, к айтюнсу FLAC вообще никак не прикрутить.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	25. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 01:46
	>> И да, mp3 должен умереть! Да здравствует ogg! > У меня такое ощущение, что mp3 и jpeg проживут еще не один > десяток лет. Хорошо хоть flac вовремя занял свою нишу. Теперь даже > ms и apple не могут его вытеснить. К сожалению вы правы…
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	76. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от freehck (ok) on 11-Ноя-16, 18:18
	Как-то неоднозначно, Вы не находите? :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	79. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 19:18
	Согласен. Сожаление относиться к первой части сообщения.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	34. "В Fedora добавлена встроенная поддержка MP3"	–2 +/–
	Сообщение от iPony on 11-Ноя-16, 06:34
	> Хорошо хоть flac вовремя занял свою нишу. Теперь даже ms и apple не могут его вытеснить. Ну как-то это особо не пересекается. Музыканты с Wav работают, магазины продают в aiff, mp3, wav. FLAC в основном на поррентах.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	46. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 11:42
	> магазины продают > в aiff, mp3, wav. Особо не интересовался, но на bandcamp часто предлагают flac. Некоторые музыканты выкладывают hd (24bit/96kHz) в flac. Есть и специализирующиеся магазины типа https://allflac.com > FLAC в основном на поррентах. А также для личных коллекций. В любом случае flac стал стандартом de facto для сжатия музыки без потерь.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	57. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 11-Ноя-16, 14:54
	> Особо не интересовался, но на bandcamp часто предлагают flac. Некоторые музыканты выкладывают Понятно, что есть исключения, я же про правила. PS: На том же bandcamp бывает flac - это тупо апскейленный mp3
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	84. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 20:11
	> Понятно, что есть исключения, я же про правила. А что - правила? Даже мой древнючий N900 играет и FLAC, и vorbis и opus. А то что тыблоко за всех своих хомяков решает как их доить правильно - ни для кого не секрет.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	94. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 12-Ноя-16, 05:01
	А причем тут вообще это? речь о другом была совсем.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	103. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Аноним (??) on 12-Ноя-16, 18:44
	> А причем тут вообще это? речь о другом была совсем. А это при том что ты так старательно пытаешься доказать что FLAC не надо, без opus можно обойтись, блаблабла. В принципе то можно обойтись и уютной пещеркой, у костра.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	136. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 18-Ноя-16, 13:33
	> ты так старательно пытаешься доказать что FLAC не надо, без opus можно обойтись Выдумываешь, я говорю про текущую ситуацию на рынке.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	140. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 20-Ноя-16, 05:32
	> Выдумываешь, я говорю про текущую ситуацию на рынке. А что - ситуация на рынке? На рынке усе пожрал гугиль. И веб, и смарты, и планшеты. Мало того что гугловская система сама по себе половину форматов трескает, под ведроид еще есть vlc который вообше играет все что шевелится, поскольку юзает ffmpeg, насколько я помню.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	95. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 05:53
	iTunes – не показатель. Это лишь один магазин со своими взглядами на форматы. Он крупный, но не доминирующий, так что диктовать предпочитаемые форматы не может.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	96. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 12-Ноя-16, 08:12
	> iTunes – не показатель. Меня иногда просто поражает местная публика. Где вообще была речь про Apple конкретно? Да, помимо iTunes есть крупные игроки. FLAC разве что есть у "любительского" Bandcamp и 7Digiatal (и то у этого не для Этой Страны). Lossless в подобных ресурсах - это практически всегда aiff или wav.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	104. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 19:17
	Извини, но проприетарные м...ки проталкивающие патентованные форматы по большому счету остались одни - эппл.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	129. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 16-Ноя-16, 18:59
	> Извини За ложь - нет. Все остальные дистрибьюторы музыки - google, amazon, beatport ... - естественно распространяют музыку тоже в проприетарных форматах. Уж как есть.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	135. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 18-Ноя-16, 01:15
	> За ложь - нет. Все остальные дистрибьюторы музыки - google, amazon, beatport > ... - естественно распространяют музыку тоже в проприетарных форматах. Уж как есть. Ты так прикольно расписываешься за всех. А я однако ж с jamendo в свое время vorbis'а понакачал. Так что за ложь про ВСЕХ с себя наверное и спроси, раз такой безаппеляционный правдоруб.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	137. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 18-Ноя-16, 13:35
	> Ты так прикольно расписываешься за всех. А я однако ж с jamendo в свое время vorbis'а понакачал. Замечательно, зашёл на их сайт - действительно была такая возможность, но щас выкинули. Я про общую картину, про исключения я знаю, выше про них писал. PS: "безаппеляционный правдоруб" - нет, просто КЭП
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	141. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 20-Ноя-16, 05:39
	> Замечательно, зашёл на их сайт - действительно была такая возможность, но щас > выкинули. Я про общую картину, про исключения я знаю, выше про них писал. Ну замечательно, как что-то не укладывается в твою картину мира - так это исключения. А это, ютуб битком набитый видео где аудиотреки крупным оптом в vorbis и opus - это ничего? И таки да, народ туда льет и "видео" состоящие из аудиотрека + обложки. Поэтому ютуб до кучи котируется и за склад аудио. Качество конечно не гарантировано в отличие от специальных ресурсов, но все-таки. > PS: "безаппеляционный правдоруб" - нет, просто КЭП Скорее, недальновидный боклан, который не видит даже огроменный ютуб.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	146. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 21-Ноя-16, 07:53
	> Скорее <CENSORED> который не видит даже огроменный ютуб. Здрасьте, а мы тут про магазины музыки говорили. У гугла оно называется Google Play и там насколько я понимаю кроме MP3 с фонарем что-то трудно найти...
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	150. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 22-Ноя-16, 15:36
	> Здрасьте, а мы тут про магазины музыки говорили. А что, Эппл у себя перестал юзать aac и прочие lossless?
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	10. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от абвгдейка (ok) on 11-Ноя-16, 00:09
	кому должен?:)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	23. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 01:43
	Здравому смыслу!
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "В Fedora добавлена встроенная поддержка MP3"	+3 +/–
	Сообщение от Crazy Alex (ok) on 11-Ноя-16, 00:13
	Кодек как кодек. Его в своё время до ума довели, суперсжатие сейчас не актуально, патенты на него почти закончились (точнее - закончились везде кроме Штатов) так что, в принципе, абсолютно нормлаьный вариант
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	17. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 00:52
	> суперсжатие сейчас не актуально, А чуваки из гугля вот тут на днях сказали что бандвиз - основная статья их расходов. Поэтому по части сжатия они вджобывают конкретно. Да и остальных вебня сильно подгоняет. Opus вон запилили - он даже aac he делает убедительно. И мигом внедрили во всю вебню, потому что бандвиз же.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	20. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 01:12
	> А чуваки из гугля вот тут на днях сказали что бандвиз - > основная статья их расходов. Надо полагать, что речь о видео. Так как аудио поток - это лишь 2-10% от видео потока. > Opus вон запилили - он даже aac he делает убедительно. Есть еще один важный фактор (для мобильных устройств) - энергопотребление при декодировании. В порядке увеличения потребления: wav, flac, mp3, vorbis, opus.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	24. "В Fedora добавлена встроенная поддержка MP3"	–3 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 01:43
	> Надо полагать, что речь о видео. Так как аудио поток - это лишь 2-10% от видео потока. Тем не менее, поскольку это помножено на миллиарды - там экономия каждого бита отливается в гигабайты. > Есть еще один важный фактор (для мобильных устройств) - энергопотребление > при декодировании. А вот это уже их проблемы. Хотя в целом перцы из гугеля и скоростью декодирования заинтересованы, если это не в ущерб плотности, так сказать. > В порядке увеличения потребления: wav, А вот давайте без такого ламерства, особенно от вас? Wav - это RIFF контейнер в котором может быть ЧТО УГОДНО. Из такого развеселого - попадались wav с встроеным MP3. Нормально так? :) > flac, mp3, vorbis, opus. Как все это замерялось? Такие заявления требуют больше данных.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	28. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 02:24
	>> Надо полагать, что речь о видео. Так как аудио поток - это лишь 2-10% от видео потока. > Тем не менее, поскольку это помножено на миллиарды - там экономия каждого > бита отливается в гигабайты. Да, но пока из видео не выжмут все возможное, оптимизация размера аудио имеет мала смысла. Очевидно поэтому столько много новых видео кодеков и практически тишина среди аудио. >> Есть еще один важный фактор (для мобильных устройств) - энергопотребление >> при декодировании. > А вот это уже их проблемы. Это проблемы которые коснуться пользователя: если плеер будет работать 8 часов на opus вместо 16 на mp3 - судьба opus решена. На форуме rockbox часто спрашивают какой формат лучше именно по этому параметру, так как многих беспокоит продолжительность автономной работы. >> В порядке увеличения потребления: wav, > А вот давайте без такого ламерства, особенно от вас? Давайте не придраться к словам, вы как и 99% людей понимаете, что под wav обычно подразумевает pcm_s16le/44.1kHz/16bit - ибо стандарт cd audio. Если говорят о чем-то более специфическом - тогда да, лучше полностью указать стандарт кодирования. >> flac, mp3, vorbis, opus. > Как все это замерялось? Такие заявления требуют больше данных. https://www.rockbox.org/wiki/CodecPerformanceComparison Смотрите последнюю/предпоследнюю графу - там где MHz - это сколько MHz нужно, чтобы проигрывать данный формат на данном железе в реальном времени.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	82. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 20:07
	> Да, но пока из видео не выжмут все возможное, оптимизация размера аудио имеет мала смысла. Имеет смысл параллельная работа и оптимизация по всем фронтам. И возможность послушать аудио даже по тощему каналу интернета без икоты - хорошо и правильно. > Очевидно поэтому столько много новых видео кодеков и практически тишина среди аудио. Я бы не назвал vorbis а потом и opus тишиной, да и AAC что-то там пытался, но opus его порвал на британский флаг. Появилось чуть не полдюжины lossless кодеков. А видео - там выигрыш потенциально выше, еще много чего не опробовано. Логично что и внимания больше. Это однако не повод слать аудитотреки неэффективно. > Это проблемы которые коснуться пользователя: если плеер будет работать 8 часов на > opus вместо 16 на mp3 - судьба opus решена. Большинство юзерей нынче музыку слушают на смарте и там это не основная статья расходов батарейки. А тощие тарифы мобильных интернетов отмеряные пипеткой кого угодно заставят любить эффективный формат. В mp3 даже послушать онлайн радио - очень скоро превращает тариф в тыкву. Да и владельцу сервера в 2 раза больше бандвиза - это в 2 раза меньше юзерей за те же деньги. И если уж на то пошло, в два раза больше траффика беспроводки - убьет любую экономию. Беспроводка выдувает энергию в эфир в самом прямом смысле слова. > На форуме rockbox часто спрашивают какой формат лучше именно по этому параметру, так > как многих беспокоит продолжительность автономной работы. На форуме rockbox - крайне нерепрезентативная аудитория. Которая де факто ничего не решает за пределами своей узенькой тусовочки. А в интернете опус разъехался широко, ютуб в нем сейчас аудио у vp9 мувиков делает и даже мерзкософт запилил его в своем edge. > Давайте не придраться к словам, вы как и 99% людей понимаете, что > под wav обычно подразумевает pcm_s16le/44.1kHz/16bit - ибо стандарт cd audio. В отличие от 99% людей я понимаю что в WAV можно засунуть что угодно. Да и "стандарт CD аудио" нынче уже вымираюший вид - продажи сидюков сдохли. По этому поводу даже стандартной рабочей частотой аудио железок в последнее время стали 48кГц и кратные. > https://www.rockbox.org/wiki/CodecPerformanceComparison Это уже ближе к делу. > Смотрите последнюю/предпоследнюю графу - там где MHz - это сколько MHz нужно, > чтобы проигрывать данный формат на данном железе в реальном времени. Только там процессоры ископаемые. ARMv7 я там не вижу совсем. Про всякие NEOn и проч simd/dsp команды присутствующие в современных процах я вообще молчу. Результаты ARM926EJS на 40 МГц это так мило в 2016 году. Но даже мой древний N900 - это ARMv7 на 600МГц. Ему все эти треки - процентов на 5 нагрузки самый край. И будет там 2% или 5% скорее всего погоды не сделает, проц в обоих случаях будет на минимальной частоте ползать.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	90. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 02:17
	> Я бы не назвал vorbis а потом и opus тишиной, да и > AAC что-то там пытался, но opus его порвал на британский флаг. > Появилось чуть не полдюжины lossless кодеков. Притом все они (кроме opus) появились более 10 лет назад. Сравните с видео - там что не год - новый кодек, а то и несколько. > А видео - там выигрыш потенциально выше, еще много чего не опробовано. > Логично что и внимания больше. Это однако не повод слать аудитотреки > неэффективно. ИМХО основной потенциал был выжат еще из mp3 и все новые кодеки не могут существенно (на 50-100% как в видео) улучшить результат. > Большинство юзерей нынче музыку слушают на смарте и там это не основная > статья расходов батарейки. Хотите сказать, что смарт в режиме плеера проживет примерно столько же, сколько и в режиме ожидания? > А тощие тарифы мобильных интернетов отмеряные пипеткой кого > угодно заставят любить эффективный формат. В mp3 даже послушать онлайн радио > - очень скоро превращает тариф в тыкву. Есть такая беда, но ИМХО связана она с локальной недоразвитостью интернета. >  Да и владельцу сервера > в 2 раза больше бандвиза - это в 2 раза меньше > юзерей за те же деньги. И если уж на то пошло, > в два раза больше траффика беспроводки - убьет любую экономию. Беспроводка > выдувает энергию в эфир в самом прямом смысле слова. Это да, аргумент. Но если человек хранит музыку в облаке - то естественно у него будут проблемы как с доступом, так и с трафиком и временем автономной работы >> На форуме rockbox часто спрашивают какой формат лучше именно по этому параметру, так >> как многих беспокоит продолжительность автономной работы. > На форуме rockbox - крайне нерепрезентативная аудитория. Которая де факто ничего не > решает за пределами своей узенькой тусовочки. Большинство меломанов хранят музыку в lossless ибо место на hdd очень дешево. Но многие хотят впихнуть свою коллекцию на портативные устройства и спрашивают - какой формат лучше. > А в интернете опус разъехался > широко, И много в нем музыки выкладывают? Даже vorbis чаще попадается. > ютуб в нем сейчас аудио у vp9 мувиков делает и google, как и apple/ms - делает, что хочет. На практике я пока по прежнему использую x264, так как кодирование в vp9 слишком медленно, а поддержка видео редакторами - близка к нулю. >> Давайте не придраться к словам, вы как и 99% людей понимаете, что >> под wav обычно подразумевает pcm_s16le/44.1kHz/16bit - ибо стандарт cd audio. > В отличие от 99% людей я понимаю что в WAV можно засунуть > что угодно. Это хорошо. Просто не нужно цепляться к словам, тут и так таких любителей хватает - в итоге флейм и ругань на ровном месте, вместо конструктивного диалога. Если вам не понятно, что конкретно человек сказал - попросите пояснить. Сам я с этим чудом (mp3 в wav) столкнулся еще в начале 2000х на пиратской дискографии - ни один аппаратный плеер не хотел воспроизводить этот диск :( > Да и "стандарт CD аудио" нынче уже вымираюший вид > - продажи сидюков сдохли. А стандарт остался. У меня 100% музыки (~200 GB) в 44.1kHz. > По этому поводу даже стандартной рабочей частотой > аудио железок в последнее время стали 48кГц и кратные. Смотря для каких - если ориентация игры и фильмы - то да. Если музыка то - нет. Хорошее железо умеет оба формата одинаково хорошо. >> Смотрите последнюю/предпоследнюю графу - там где MHz - это сколько MHz нужно, >> чтобы проигрывать данный формат на данном железе в реальном времени. > Только там процессоры ископаемые. ARMv7 я там не вижу совсем. Про всякие > NEOn и проч simd/dsp команды присутствующие в современных процах я вообще > молчу. На спец soc есть и отдельный блок imdct36, но это только значит - что все форматы станут эффективнее при декодировании. Разница же между ними так и останется. Более сложная модель кодирования требует больше ресурсов и с этим ничего не поделаешь. > Результаты ARM926EJS на 40 МГц это так мило в 2016 > году. Но даже мой древний N900 - это ARMv7 на 600МГц. Стандартно - 250 MHz. 40 - это нижняя частота при freq/voltage scaling. > Ему все эти треки - процентов на 5 нагрузки самый край. > И будет там 2% или 5% скорее всего погоды не сделает, > проц в обоих случаях будет на минимальной частоте ползать. Это как раз и плохо. Если у вас остается более чем двукратный запас при воспроизведении mp3 - значит ваше устройство в пустую садит акб.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	106. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 21:29
	> Притом все они (кроме opus) появились более 10 лет назад. А дорабатывались и потом. И к тому же опус сделан как гибрид 2 разных кодеков, которые были и разрабатывались. И по своему уникален: может быть speech-кодеком на низких битрейтах, может приемлимо транслировать музыку на битрейте повыше, а на 64Кбит народ не может отличить его от сидюка в слепом тесте. > Сравните с видео - Да, давайте сравним - сколько лет был один H.264 и сколько лет его все вообще реализовывали? > там что не год - новый кодек, а то и несколько. Реально живых всего несколько кодеков на самом деле. Остальное лабораторные прототипы и/или nextgen nextgen'а. > ИМХО основной потенциал был выжат еще из mp3 и все новые кодеки > не могут существенно (на 50-100% как в видео) улучшить результат. Opus на 64кбит звучит лучше чем mp3 на 128. Ессно VBR/среднее. Как раз улучшение в 2+ раза и есть. Вату в 128 кбит на мониторах слушать печально. А 64кбит опус - не заметишь подвох так сразу. > Хотите сказать, что смарт в режиме плеера проживет примерно столько же, сколько > и в режиме ожидания? Ессно он проживет меньше. А хотя-бы потому что power gating и clock gating большинству блоков сделать уже не получится - они катят только если активность нулевая. И как минимум все статичные утечки будут выше в разы. На низких частотах это может быть вообще выше чем потребление переключающихся вентилей. ИМХО на смартах и т.п. это стоило бы тестануть как-то так: - Полностью заряжаем батарейку. Гоняем MP3 по кольцу пока не сядет. Замеряем время. - Аналогично с {opus, vorbis, aac, wav, flac, ...}. Но это потребует МНОГО времени на тест и я не знаю как это хорошо автоматизировать. >> - очень скоро превращает тариф в тыкву. > Есть такая беда, но ИМХО связана она с локальной недоразвитостью интернета. Связана она с тем что оборудование для сотовых операторов стоит конских денег, а частоты ограничены и доступный бандвиз делится на толпу. > Это да, аргумент. Но если человек хранит музыку в облаке Это обычный жизненный сценарий "интернет-радио послушать". > Большинство меломанов хранят музыку в lossless ибо место на hdd очень дешево. У меня и видео есть нежатое - чтобы объективно мерять что могут видеокодеки. > Но многие хотят впихнуть свою коллекцию на портативные устройства и спрашивают > - какой формат лучше. Ну вот за опуса говорит хорошее качество при минимальном размере. ИМХО 64 кбит опуса выше крыши для мобильных устройств. Звучать будет лучше mp3@128kbps а места займет в 2 раза меньше. Юзеры смартов один фиг заряжаются раз в 1-2 дня а то и таскают power bank даже без всяких плееров, т.к. любят в сети повисеть. > И много в нем музыки выкладывают? Даже vorbis чаще попадается. Так vorbis и появился раньше, не говоря про mp3. А так - да вон весь ютуб, там народ любит выкладывать видео из обложки + аудиотрека. > google, как и apple/ms - делает, что хочет. На практике я пока > по прежнему использую x264, так как кодирование в vp9 слишком медленно, > а поддержка видео редакторами - близка к нулю. А я использую VP9, мне нравится. Сразу в вебе играется в большинстве браузеров и битрейт/качество мне нравятся. Из x264 я в принципе такое выжать не могу. Скорость кодирования там регулируется, а если мне хочется максимальное качество при минимальном размере - пущу пахать на мощном десктопе, хоть на ночь. > Это хорошо. Просто не нужно цепляться к словам, тут и так таких > любителей хватает - в итоге флейм и ругань на ровном месте, Меня утомило что люди по жизни путают и не понимают форматы данных, поэтому возможно я слишком придирчив на этот счет, уж пардон. > Сам я с этим чудом (mp3 в wav) столкнулся еще в начале > 2000х на пиратской дискографии - ни один аппаратный плеер не хотел > воспроизводить этот диск :( Пираты ориентировались на писюки. И собссно я вижу пойнт смартфонов в том что они по свойствам более похожи на писюки. И если что-то не играется... на андроиде есть vlc, на n900 - mplayer. И там ffmpeg, он жует все что шевелится, если проца хватает. Хорошо. > А стандарт остался. Да и фиг с ним. Помрет вместе с своими цифровыми грампластинками, имхо. > У меня 100% музыки (~200 GB) в 44.1kHz. А у меня - полнейший разнобой. Потому что из разных мест и проч и я не вижу почему я должен утыкаться в стандарт цифровых грампластинок из 80-х прошлого века. Да и нативные частоты железа у меня в основном 48кГц и кратные. >> аудио железок в последнее время стали 48кГц и кратные. > Смотря для каких - если ориентация игры и фильмы - то да. Смарты/планшеты/одноплатники, писюки и лаптопы, ... - дружно выбрали 48кГц. На что они ориентированы? Они general purpose. > Если музыка то - нет. Хорошее железо умеет оба формата одинаково хорошо. Нынче куча музыки и 24 бит/192 кГц бывает. Летучие мыши одобряют. > На спец soc есть и отдельный блок imdct36, но это только значит > - что все форматы станут эффективнее при декодировании. Говоря за себя - меня только general purpose устройства по жизни интересуют, которые полностью реконфигурабельны софтварно. Я не считаю себя готовым утыкаться в один стандарт или алгоритм навечно. Люди придумают новые, более удачные стандарты и алгоритмы. > Разница же между ними так и останется. Более сложная модель кодирования > требует больше ресурсов и с этим ничего не поделаешь. А мне ничего и не требуется с этим делать. Даде на винтажном смарте N900, с его 600МГц cortex A8. Будет там 2% cpu или целых 4% - мало влияет на что либо. > Стандартно - 250 MHz. 40 - это нижняя частота при freq/voltage scaling. Я не знаю для кого это "стандарт". Для меня нижняя планка стандартов - Cortex A8 @ 600MHz. Дохлее у меня есть разве что MIPSовый роутер на 400МГц, но на нем музыку слушать все-таки совсем изврат. И Nokia N800 с 400MHz процом, на правах музейного экспоната. Однако ж этого музея хватает на _кодирование_ видео mpeg4 320x240x12FPS с тамошней тетрисообразной камеры. Даже этому музею декодирование что vorbis, что opus - на один зубок. > Это как раз и плохо. Если у вас остается более чем двукратный > запас при воспроизведении mp3 - значит ваше устройство в пустую садит акб. А это особенности CMOS-схемотехники. Кроме динамического потребления есть еще и статическое. Схемы потребляют ощутимую мощноть даже если ничего не делают. В современных железках из-за числа транзисторов и уменьшения толщины изоляторов эффект довольно сильный. С ним првда борятся DVFSом и просто и power gating'ом во все поля. Ну и clock gating для экономии и в динамике заодно. А так то да - круче всего отлить ASIC за доллар с правильным форматом, будет энергоэффективно что пипец. Но вот менять его каждый раз при смене формата мне как-то лениво. И транскодировать форматы лишний раз под всякий крап меня тоже не прельщает лишний раз. Лучше всего когда девайс всеяден :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	110. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 13-Ноя-16, 03:17
	> а на 64Кбит народ не может отличить его от сидюка в слепом тесте. > Opus на 64кбит звучит лучше чем mp3 на 128. Ессно VBR/среднее. Как > раз улучшение в 2+ раза и есть. Вату в 128 кбит > на мониторах слушать печально. А 64кбит опус - не заметишь подвох > так сразу. Скажу честно, вы меня заинтриговали и я подумал - а вдруг? Но нет, чуда не произошло :) Да верха у opus другие без характерного "зажовывания" как в mp3. Но, за все приходится платить. У обоих (mp3/128 и opus/64) звучание более плоское и менее выразительное. У mp3 понятно - местами зажованые верха. У opus другой характер искажений - верха упрощенные и более глухие. Но самый косяк - стереопанорама - местами на тарелках она практически полностью сворачивается в моно. Да и хвост реверберации короче. Специально прослушал этот же фрагмент на mp3 - ничего подобного нет. В целом все же mp3 128 лучше, но местами его верха действительно раздражают. Возможно opus/96 и смог бы действительно обыграть mp3/128. Но в любом случае о cd audio качестве речи пока нет. Хотя, с учетом битрейта, opus/64 звучит весьма пристойно и при необходимости сильной экономии битрейта хороший вариант. Немного о моей методике тестирования: беру два файла и объединяю в один mkv контейнер, затем в плеере нажатием одной клавиши переключаюсь между треками в реальном времени. Для слепого теста - закрываю глаза и долблю клавишу как Поттеринг завещал (более 7 раз за 2 секунды).Я так обычно ремастеры сравниваю. > ИМХО на смартах и т.п. это стоило бы тестануть как-то так: > - Полностью заряжаем батарейку. Гоняем MP3 по кольцу пока не сядет. Замеряем > время. > - Аналогично с {opus, vorbis, aac, wav, flac, ...}. Глянул свой смарт с андройдом (подключил мультиметр между акб и телефоном)  - разница между форматами не большая - он тупо во всех случаях жрет в 3-4 раза больше аппаратного плеера. >> google, как и apple/ms - делает, что хочет. На практике я пока >> по прежнему использую x264, так как кодирование в vp9 слишком медленно, >> а поддержка видео редакторами - близка к нулю. > А я использую VP9, мне нравится. Сразу в вебе играется в большинстве > браузеров и битрейт/качество мне нравятся. Из x264 я в принципе такое > выжать не могу. Мне вначале тоже так казалось. Затем сделал кучу отдельных кадров для разного качества и разных кодеков - различия минимальны (x264 более четкий, но блоки сильнее видны, vp9 без блоков, но мылит). А по времени как не шамань с настройками - существенно дольше. >> А стандарт остался. > Да и фиг с ним. Помрет вместе с своими цифровыми грампластинками, имхо. Да вроде не собирается, да и смысл его менять - качество перекрывает человеческие потребности. 24/96 реально нужно только студиям звукозаписи. Если бы не жадность sony, то не было бы вообще 48 kHz и был бы единый стандарт 44.1. > А у меня - полнейший разнобой. Потому что из разных мест Интересно откуда? Уж не ресемплинг ли из 44.1? Или уже есть студии издающий музыку в 48? Это кстати минус opus - он жестко завязан на 48 и гоняет ресемплинг туда-сюда. > Смарты/планшеты/одноплатники, писюки и лаптопы, ... - дружно выбрали 48кГц. На что они > ориентированы? Они general purpose. Они - ширпотреб, там качество аудио вторично. Все приличные аудиоплаты умеют обе частоты. Плееры - 44.1. Смарты - тут наверное как повезет. Я вот тоже думал что они на 48. Проверил свой - оказался именно 44.1. Вероятно соображают, что качество для музыки важнее, чем для фильмов/игрушек. Так что проверяйте конкретные аппараты. >> На спец soc есть и отдельный блок imdct36, но это только значит >> - что все форматы станут эффективнее при декодировании. > Говоря за себя - меня только general purpose устройства по жизни интересуют, > которые полностью реконфигурабельны софтварно. Я не считаю себя готовым утыкаться в > один стандарт или алгоритм навечно. Люди придумают новые, более удачные стандарты > и алгоритмы. Это раньше за конкретные форматы цеплялись - теперь делают отдельные спец блоки (типа упомянутого imdct36), которые используются практически во всех кодеках. То есть аппаратно ускоряют отдельные наиболее затратные алгоритмы используемые всеми. >> Стандартно - 250 MHz. 40 - это нижняя частота при freq/voltage scaling. > Я не знаю для кого это "стандарт". Стандартно для того soc. >> Это как раз и плохо. Если у вас остается более чем двукратный >> запас при воспроизведении mp3 - значит ваше устройство в пустую садит акб. > А это особенности CMOS-схемотехники. В смысле? На более низких частотах он не работает? > Схемы потребляют ощутимую мощноть даже если ничего не делают. Так я и говорю - снижать частоту так, что бы mp3 ворочал + небольшой запас (а не в два-четыре раза). Затем понижать напряжение, так как частота мало что дает сама по себе.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	114. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 13-Ноя-16, 08:12
	> Скажу честно, вы меня заинтриговали и я подумал - а вдруг? Но нет, чуда не произошло :) Для чуда надо честно делать слепые тесты с несколькими кодеками + оригиналом, на нескольких композициях и на нескольких битрейтах и набрать статистику :P. > Да верха у opus другие без характерного "зажовывания" как в mp3. Если дотошно сравнивать оригинал vs сжатый 64kbit опус - отличия заметить можно, но они не назойливые и трудноуловимые. Для чего-то такого психоакустика и нужна. > Но, за все приходится платить. У обоих (mp3/128 и opus/64) звучание более > плоское и менее выразительное. У mp3 понятно - местами зажованые верха. На битрейтах характерных для опуса (64-128кбит) mp3 нечего ловить, имхо. > этот же фрагмент на mp3 - ничего подобного нет. В целом > все же mp3 128 лучше, но местами его верха действительно раздражают. Как по мне, у мп3 при 128 кбит на ударниках - жесть. Почти буквально. > Возможно opus/96 и смог бы действительно обыграть mp3/128. Так попробуйте если не лениво. > Но в любом случае о cd audio качестве речи пока нет. Это статистически - довольно много людей не могут отличить. Я вполне допускаю что кому-то их психоакустика ниже среднего. И все-таки. > Хотя, с учетом битрейта, opus/64 звучит весьма пристойно и при необходимости сильной > экономии битрейта хороший вариант. ИМХО при равном качестве опус примерно в 2 раза меньше чем mp3. И это таки достаточно серьезно чтобы это игнорировать. Люди работали и это дало приличный результат. > клавишу как Поттеринг завещал (более 7 раз за 2 секунды).Я так > обычно ремастеры сравниваю. Вполне приличная методика вроде. > Глянул свой смарт с андройдом (подключил мультиметр между акб и телефоном)   > - разница между форматами не большая - он тупо во всех > случаях жрет в 3-4 раза больше аппаратного плеера. Я думаю что у него проц болтается на частоте близкой к минимуму и большая часть потребления - не столько динамическое потребление проца, сколько сам факт что блоки проца и прочие под напряжением, включены клоки и активны всякие служебные сущности. Они лопают больше чем динамическое потребление проца на такой нагрузке. А то что больше плеера трескает - проц более жирный, техпроцесс тоньше, транзисторов больше. Статичные утечки выше и вспомогательных блоков там больше. Ну это так, мое имхо почему оно вот так. > Мне вначале тоже так казалось. Затем сделал кучу отдельных кадров для разного качества 1) восприятие стопкадров и движущихся картинок - не одинаковое. 2) возвращаясь к назойливости артефактов, vp9 становится размытым, x264 скорее рассыпается на блоки. Из-за сочетания 1) и 2) основательно сжатое vp9 видео выглядит отнсительно беспаливно, тогда как x264 выглядит неприятно. И в целом если целиться в агрессивную экономию битрейта vp9 "сильнее" по достижимому битрейт/качество. А если битрейта более чем достаточно - все кодеки более-менее похожи. > и разных кодеков - различия минимальны (x264 более четкий, но > блоки сильнее видны, vp9 без блоков, но мылит). И что характерно - на движущейся картинке глаз плохо различает мелкие объекты и поэтому размытость довольно сложно заметить, а блоки довольно агрессивно мозолят глаза. Еще x264 имеет свойство гробить титры до совершенно нечитаемой мазни. И титры еще ладно, но ведь бывают еще записи конференций и презентаций со всякими слайдами. И вот там то может уже порядком испортить настроение. > А по времени как не шамань с настройками - существенно дольше. Там можно задать максимальное время которое кодек тратит на кадр. Он может даже реалтаймное кодирование. Но разумеется соотношение битрейт/качество ухучшится. Однако ж фокус в том что у VP9 можно использовать более тормозные режимы чтобы битрейт/качество поднять. А x264 - там уже некуда. Его до таких величин невозможно разогнать никакими манипуляциями вообще. Хотя мне понравился av1. FullHD нежатая тестовая последовательность tos3k выглядела прилично на жалких 500 килобитах. > Да вроде не собирается, да и смысл его менять - качество перекрывает > человеческие потребности. 24/96 реально нужно только студиям звукозаписи. Скорее летучим мышам, чтобы наслаждаться ультразвуком. А вот как у остальных оборудованеи отнесется к ультразвуку - очень отдельный вопрос. Один из кадров с xiph.org подробно объяснил почему это может быть плохо, у него есть веселые записи в ультразвуке. В лучшем случае их не слышно. В хучшем - они демонстрируют как ультразвук может превратиься в паразитный звук на неидеальностях. > Если бы не жадность sony, то не было бы вообще 48 kHz и был бы единый стандарт 44.1. Насколько я вижу - 48 кГц предпочли большинство производителей general purpose железяк. И это ожидаемо. 48кГц получаются из типовых тактовых сигналов делением нацело счетчиком. Например все кто что-то делал с юсб - дружно любят 12МГц. А что такое 44100 и как это получать без костылей? > Интересно откуда? Уж не ресемплинг ли из 44.1? Или уже есть студии > издающий музыку в 48? Да вон тут новая мода выпускать в 192/24. Студиям какое дело сейчас до сидючных стандартов? Сидюки умерли как формат распостранения. Онлайн их убил. А в онлайне что? Ну вот им и делают удобно. > Это кстати минус opus - он жестко завязан на 48 и гоняет ресемплинг туда-сюда. На большинстве оборудования как раз никакого ресемплинга нет. И наверное логично что он сделан так чтобы обслуживать нужды большинства пользователей рационально. Добро пожаловать в будущее. И в этом будущем я вообще никак не могу вспомнить где у меня сидюки. > Они - ширпотреб, там качество аудио вторично. Все приличные аудиоплаты умеют обе частоты. Они сделали как им проще. А что такое 44100 и почему им надо пользоваться - я не понимаю. > Плееры - 44.1. Смарты - тут наверное как повезет. Я вот тоже > думал что они на 48. Проверил свой - оказался именно 44.1. Таки по тому что я вижу - большинство SoC нативно умеет именно 48кГц или что-то кратное. И такая фигня в "щирпотребе" начиная с чуть ли не AC97 и древних писюков. 44.1 железки сейчас сравнительно редки. А что за SoC у вашего смарта? > Вероятно соображают, что качество для музыки важнее, чем для фильмов/игрушек. Так > что проверяйте конкретные аппараты. Я не собираюсь цепляться за издыхающий стандарт. У сидюков нет будущего, а 48 кГц технически выгдядят рациональнее. Да и хомяки нынче любят 24/192. И поэтому индустрия в основном имхо переориентируется туда, имхо. А любители 44100 будут все больше заниматься редискретизацией, имхо. А просто потому что основной доход - не с них. > Это раньше за конкретные форматы цеплялись - теперь делают отдельные спец блоки > (типа упомянутого imdct36), которые используются практически во всех кодеках. Тезис о том что всегда будет только DCT вилами по воде писан. В видео уже начинают опробовать альтернативные техниики. А аудио и видео частично похожи. PVQ перенесли же с аудио на видео, насколько я помню. Вот прямо в av1 и будет. > То есть аппаратно ускоряют отдельные наиболее затратные алгоритмы используемые всеми. Оно как бы логично но накладывает ограничения на классы алгоритмов а "затратные алгоритмы" занимают 2-5% антикварного апликушника. Для современного вообще - "не видно на радаре". >>> запас при воспроизведении mp3 - значит ваше устройство в пустую садит акб. >> А это особенности CMOS-схемотехники. > В смысле? На более низких частотах он не работает? В смысле у CMOS есть статическое потребление а есть динамическое. Даже если вы остановите все клоки и динамическое потребление придет в ноль т.к. емкости более не перезаряжаются, это не значит что ток станет ноль. В простых чипах он и правда будет близок к нолю. Но в более тонких чипах с миллионами транзисторов - паразитные утечки обеспечивают весьма приличное потребление даже если чип остановили совсем но оставили под напряжением. Поэтому сейчас используют DVFS (напряжение понижают, так что на малых частотах этого хватает, а токи утечки снижаются). А совсем неиспользуемые блоки - отрубают целиком по питанию (power gating). Ну и в результате - сам факт что вы что-то делали будит проц, блоки под напряжением - и вот вам ваши утечки и прочий общесистемный оверхед. Ну я и прикинул что все это может вообще перевесить те крохи которые приходятся на динамическое потребление проца. Судя по вашим результатам замеров я еще и угадал. > Так я и говорю - снижать частоту так, что бы mp3 ворочал > + небольшой запас (а не в два-четыре раза). Затем понижать напряжение, > так как частота мало что дает сама по себе. Напряжение понижать по многим причинам. Потребление CMOS пропорционально как минимум квадрату питающего напряжения по чисто динамическим причинам перезарядки кондеров (энергия кондера C*U^2/2). Но если напряжение будет недостаточным для данной частоты - чип дестабилизируется. На высокой частоте и напряжение приходится поднимать, что обеспечивает очень крутой рост потребления с повыением частоты. А на маленькой частоте и напряжение можно снизить. Это уменьшает и статичные токи утечек которые есть незаивисимо от переключений. Не говоря о том что медленная схема с низким напряжением питания значительно энергоэффективнее из-за понижения C*U^2/2 (идущих на переключение полевика). Но даже с пониженным напряжением - статичные утечки будут отличны от ноля. Клоки будут тикать и будет некое динамическое потребление. Начиная с какого-то момента дальнейшее понижение частоты почти не дает эффекта и даже совсем остановленный чип потребляет отнюдь не ноль.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	119. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 14-Ноя-16, 04:03
	> Для чуда надо честно делать слепые тесты с несколькими кодеками + оригиналом, > на нескольких композициях и на нескольких битрейтах и набрать статистику :P. Мне хватило и первого трека :) >> Да верха у opus другие без характерного "зажовывания" как в mp3. > Если дотошно сравнивать оригинал vs сжатый 64kbit опус - отличия заметить можно, > но они не назойливые и трудноуловимые. Для чего-то такого психоакустика и > нужна. Да и это хорошо, для некоторых ситуаций - ты просто не замечаешь, чего лишился и можешь спокойно пережить. Но все же, без явной необходимости, не стоит так издеваться над собой ;) >> Возможно opus/96 и смог бы действительно обыграть mp3/128. > Так попробуйте если не лениво. Немного лениво. Но хочу еще жене поставить, она музыкант - интересно какие проблемы она отметит. >> Но в любом случае о cd audio качестве речи пока нет. > Это статистически - довольно много людей не могут отличить. Я вполне допускаю > что кому-то их психоакустика ниже среднего. И все-таки. Тут еще вопрос на чем и в каких условиях они слушают. >> Хотя, с учетом битрейта, opus/64 звучит весьма пристойно и при необходимости сильной >> экономии битрейта хороший вариант. > ИМХО при равном качестве опус примерно в 2 раза меньше чем mp3. > И это таки достаточно серьезно чтобы это игнорировать. Люди работали и > это дало приличный результат. Ну не в два, но в полтора - возможно. Да и по результатам оценок на их сайте примерно так и получается. > Я думаю что у него проц болтается на частоте близкой к минимуму > и большая часть потребления - не столько динамическое потребление проца, сколько > сам факт что блоки проца и прочие под напряжением, Статика (режим самолет) - 20-25 мА. Динамика еще добавляет 15-20 мА в зависимости от формата. > А то что больше плеера трескает - > проц более жирный, техпроцесс тоньше, транзисторов больше. Статичные утечки выше и > вспомогательных блоков там больше. Ну это так, мое имхо почему оно > вот так. ИМХО все равно много. Явно плохо оптимизирован - динамика на clip zip 3-5 мА и это с его древним cpu. >> Мне вначале тоже так казалось. Затем сделал кучу отдельных кадров для разного качества > 1) восприятие стопкадров и движущихся картинок - не одинаковое. Естественно, сравнивал на практически не подвижных фрагментах. > Из-за сочетания 1) и 2) основательно сжатое vp9 видео выглядит отнсительно беспаливно, > тогда как x264 выглядит неприятно. И в целом если целиться в > агрессивную экономию битрейта vp9 "сильнее" по достижимому битрейт/качество. А если битрейта > более чем достаточно - все кодеки более-менее похожи. Меня в основном интересует q21-24 (для x264) - не вижу смысла очень сильно занижать битрейт. Хочется сохранить достаточно приличное видео, ведь смотреть я его буду и через 20 лет. Так что хочется сохранить детали. > И что характерно - на движущейся картинке глаз плохо различает мелкие объекты > и поэтому размытость довольно сложно заметить, а блоки довольно агрессивно мозолят > глаза. Да, но на средних-больших битрейтах эти блоки превращаются в детали. А у vp9 немного мыла остается. >> А по времени как не шамань с настройками - существенно дольше. > Там можно задать максимальное время которое кодек тратит на кадр. Он может > даже реалтаймное кодирование. Но разумеется соотношение битрейт/качество ухучшится. > Однако ж фокус в том что у VP9 можно использовать более > тормозные режимы чтобы битрейт/качество поднять. А x264 - там уже некуда. У меня даже телефон снимает в него в реальном времени, не говоря уж о камере :) Там 100500 настроек, в том числе и готовые пресеты: ultrafast,superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo. 720p на моей машине (пресет slow) 0.7 realtime, ultrafast - в 3.3 раза быстрее realtime. > Хотя мне понравился av1. FullHD нежатая тестовая последовательность tos3k выглядела прилично > на жалких 500 килобитах. Тоже смотрю в его сторону, но пока не пробовал. >> Да вроде не собирается, да и смысл его менять - качество перекрывает >> человеческие потребности. 24/96 реально нужно только студиям звукозаписи. > Скорее летучим мышам, чтобы наслаждаться ультразвуком. Нет. Перед оцифровкой нужно срезать весь ультразвук, дабы избежать искажений в слышимом диапазоне. Для cd audio - 22.5кГц - 20кГц = 2.5 кГц. Прикиньте, какой нужен аналоговый фильтр, дабы снизить сигнал на 96dB на таком маленьком участке? Проще оцифровать в 96-192kHz - фильтр получится с вполне приемлемой крутизной, а затем в цифровым фильтром срезать весь ультразвук и перевести в 44.1/48кГц. > Насколько я вижу - 48 кГц предпочли большинство производителей general purpose железяк. Это решения ценой в 0.5$-5$, где качество звука в прямом смысле как у AC97. > А что такое 44100 и как это получать без костылей? Любой современный  CGU (clock generation unit) без проблем справляется с этой задачей, так как имеет гибкую систему делителей и множителей. В современных SoC куча различной периферии и частоты там очень разные и далеко не всегда кратные. >> Интересно откуда? Уж не ресемплинг ли из 44.1? Или уже есть студии >> издающий музыку в 48? > Да вон тут новая мода выпускать в 192/24. И много их? 1% или 0.1%? > Студиям какое дело сейчас > до сидючных стандартов? Сидюки умерли как формат распостранения. Онлайн их убил. > А в онлайне что? Ну вот им и делают удобно. Вот именно по этому и 44.1 - так как у студий налажен под него весь конвейер. Они по прежнему выпускают cd, зачем им делать второй мастер для online? Им как раз проще выложить 44.1. > На большинстве оборудования как раз никакого ресемплинга нет. Если взять 44.1 и сжать opus - получаешь 48. Но если сделать opusdec - получаешь 44.1 ... >> Они - ширпотреб, там качество аудио вторично. Все приличные аудиоплаты умеют обе частоты. > Они сделали как им проще. А что такое 44100 и почему им > надо пользоваться - я не понимаю. Потому, что все музыка в нем. >> Плееры - 44.1. Смарты - тут наверное как повезет. Я вот тоже >> думал что они на 48. Проверил свой - оказался именно 44.1. > Таки по тому что я вижу - большинство SoC нативно умеет именно > 48кГц или что-то кратное. И такая фигня в "щирпотребе" начиная с > чуть ли не AC97 и древних писюков. На PC да - стандарт. А вот в мобильном сегменте - не факт. > 44.1 железки сейчас сравнительно > редки. Нет, как я уже сказал, это элементарно делает современный (5-10 лет) CGU. И все зависит от производителя прошивки - какую частоту захочет, ту и поставит. Раньше на дорогих платах ставили отдельные два кварца и переключались между ними - точность выше (кварцы с повышенной точностью) но относительно сложно и дорого. > А что за SoC у вашего смарта? Qualcomm MSM7227A >> Вероятно соображают, что качество для музыки важнее, чем для фильмов/игрушек. Так >> что проверяйте конкретные аппараты. > Я не собираюсь цепляться за издыхающий стандарт. У сидюков нет будущего, а > 48 кГц технически выгдядят рациональнее. Тут ситуация похожа на jpeg и mp3 - даже если есть что лучше, особого смысла менять нет и все продолжают использовать. > Тезис о том что всегда будет только DCT вилами по воде писан. Я это не утверждал. Это как с mmx/sse когда подходит - используем и ускоряемся, если не - делаем по-старинке на стандартном наборе команд. > Оно как бы логично но накладывает ограничения на классы алгоритмов а "затратные > алгоритмы" занимают 2-5% антикварного апликушника. Для современного вообще - "не видно > на радаре". Производители SoC с вами не согласны, но это их дело :) Я же лично хотел бы "вечный" плеер с зарядом от нажатия клавиш при использовании и весом в 20-30г. Для этого и нужны серьезные оптимизации. Пока при таком весе и 20-30 часов не каждый плеер осилит. > Ну и в результате - сам факт что вы что-то делали будит > проц, блоки под напряжением - и вот вам ваши утечки и > прочий общесистемный оверхед. Ну я и прикинул что все это может > вообще перевесить те крохи которые приходятся на динамическое потребление проца. Судя > по вашим результатам замеров я еще и угадал. Нет ;)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	130. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 17-Ноя-16, 10:30
	> Мне хватило и первого трека :) Чудес не бывает - lossy на 64 кбит таки lossy. Однако, не слыша рядом оригинал или не зная как звучит оригинал - сложно заметить подвох :P. > Да и это хорошо, для некоторых ситуаций - ты просто не замечаешь, Я думаю что это нормально чтобы слушать музыку на том же мобильном устройстве например. Где место может быть ограничено, а колонки на ушах могут быть непрактичны. > Немного лениво. Но хочу еще жене поставить, она музыкант - интересно какие > проблемы она отметит. В идеале слепым тестом и на разных кодеках, но это уж как ресурсы позволят. > Тут еще вопрос на чем и в каких условиях они слушают. Ну да. Хотя слепые тесты для пузомерок кодеков обычно вроде делают на нормальном оборудовании и opus там прилично смотрелся. > Ну не в два, но в полтора - возможно. Да и по > результатам оценок на их сайте примерно так и получается. ИМХО опусом на 96-128 можно заменить мп3 на 256 и выше, поэтому я его считаю ближе к двукратной разнице. > Статика (режим самолет) - 20-25 мА. Динамика еще добавляет 15-20 мА в > зависимости от формата. Интересно. Нокла около 50-55 на мои обычные уши, с обычной громкостью, трек наобум у которого была версия в mp3 и vorbis. А в самолетном режиме в idle - около 4 ма. Но это не статика. С одной стороны немного клоков тикает, с другой половину блоков и периферии гейтанули по питанию - это некая смесь. > ИМХО все равно много. Явно плохо оптимизирован - динамика на clip zip > 3-5 мА и это с его древним cpu. У него все-таки этот ваш хардварный блок и система менее разлапистая. > Естественно, сравнивал на практически не подвижных фрагментах. Видео все-таки для движущихся картинок. Кодек имеет полное право использовать эффект temporal masking для экономии битрейта. А то что это затрагивает стопкадры - видео все-таки не для публикации фотографий и скриншотов. > Меня в основном интересует q21-24 (для x264) - не вижу смысла очень > сильно занижать битрейт. Хочется сохранить достаточно приличное видео, ведь смотреть я > его буду и через 20 лет. Так что хочется сохранить детали. А q - квантизатор? Я не кодирую с постоянным квантизатором. Зачем мне пустой экран с той же квантизацией как интенсивная сцена? Это субоптимально по bit allocation, насколько я понимаю. Поэтому я обычно использую vbr с заданием желаемого среднего (определяющего какой размер файла я хочу), min (часто близкий к 0) и max (который я в принципе готов терпеть в пике). И иногда ручным лимитом на квантизаторы/кейфреймы. Хотя обычно не требуется. Нечто между crf и vbr наверное. При этом кодек может менять квантизаторы как ему удобнее, ограничения битрейта - для вменяемости результата (лимитирование CPU/bandwidth spike и желаемый размер). При этом кодек как я понимаю получит условия близкие к оптимальным и при 2-проходном кодировании без проблем отберет биты там где они не требовались и докинет где требовались, стараясь остаться в пределах желаемого размера в среднем. При этом с одной стороны я понимаю в какой размер (средний битрейт) будет. С другой вроде бы не должно мешать кодеку оптимально кодировать. > Да, но на средних-больших битрейтах эти блоки превращаются в детали. А я не фанат больших битрейтов. Зачем мне "как xvid", только еще сильнее грузящий проц? Пойнт психовизуальных махинаций - потерять максимум данных и не заметить это. > А у vp9 немного мыла остается. Не замечал особо. А титры и тому подобный мелкий текст, где это хорошо заметно у VP9 так вообще традиционно четче чем в x264 обычно получается. С вашими квантизаторами такое как вообще выглядит? Вроде это довольно высокий квантизатор. > У меня даже телефон снимает в него в реальном времени, не говоря уж о камере :) Кодек подпертый реалтаймом не может долго искать оптимальные варианты motion compensation и прочего представления субблоков. Поэтому соотношение битрейт/качество может продуть наверное даже xvid. Поэтому у меня получалось сдуть файлы с камер в РАЗЫ при том что я не могу найти дефекты даже на стопкадрах. А сотни гигз полученные в результате сдувания жирных файлов на глаз заметны хорошо. > 720p на моей машине (пресет slow) 0.7 realtime, ultrafast - в 3.3 раза быстрее realtime. Когда я перекодирую видео - я обычно использую 2-проходное кодирование и мне пофиг какой там процент от реалтайма. Для x264 я использую самый медленный пресет - если что-то перекодируется, оно наверное будет храниться долго, поэтому меня интересует оптимизация битрейт/качество прежде всего. Чтобы выглядело симпатично и не занимало терабайты. > Тоже смотрю в его сторону, но пока не пробовал. Он тоже медленный в кодировании. Но первые впечатления - по битрейт/качество он уже ощутимо делает VP9, x264 до такого уровня разогнать нереально, x265 - пилят полтора человека, в web он играться наверное не будет. Да и один из goal-ов AV1 - nextgen по сравнению с H.265 :). > Нет. Перед оцифровкой нужно срезать весь ультразвук, дабы избежать искажений в слышимом > диапазоне. Для cd audio - 22.5кГц - 20кГц = 2.5 кГц. Вообще, некоторые "золотые ущи" вроде могут слышать чуть более 20кГц, если мощность достаточна, у 21-22 кГц чтоли. У некоторых болевой порог наступает чуть выше 20кГц, хоть там и крутая кривая. > вполне приемлемой крутизной, а затем в цифровым фильтром срезать весь ультразвук > и перевести в 44.1/48кГц. Только потом зачастую забывают применить этот фильтр, в процессе обработки донавешивают еще артефакты - формат позволяет. А потом - маркетологи же сказали - всем по 24/192, да чтоб в lossless! Ну и вот, отгружают. А как по мне - пусть сразу 100 MSPS запиливают. > Это решения ценой в 0.5$-5$, где качество звука в прямом смысле как у AC97. Это большинство чипов для смартов и планшетов, встроенное аудио большинства писюков/лаптопов и проч. Большинство людей слышат через них. И поэтому удобно будет им - они больше всего денег за музыку в онлайне платят и индустрия развернется на них. Да уже в общем то. Хоть как и положено с маркетинговыми приколами, с 24/192 и ультразвуком. > Любой современный  CGU (clock generation unit) без проблем справляется с этой > задачей, так как имеет гибкую систему делителей и множителей. Это некий отдельный узкоспециализированный блок. Его элементарно нет в большинстве железяк. Дробные делители и множители для большинства железяк - экзотика. Например я без проблем синтезирую 48кГц или деривативы таймером в STM32 от типовых кварцев. А вот как 44100 или деривативы там получить - я хз. Не то чтобы тамошний DAC нацелен на качественное аудио т.к. 12 битов. Но все-таки. > В современных SoC куча различной периферии и частоты там очень разные и далеко > не всегда кратные. Это конечно зависит от. Но именно дробные множители и делители экзотика. А хомякам все-равно сейчас 24/192/lossless подавай. Маркетолоки сказали что меньше - не круто. И поэтому всем будет FullHD'ец :) > И много их? 1% или 0.1%? Учитывая что онлайн продажи перевесили физические носители - годиков через 5 поговорим чего там 0.1% :) > под него весь конвейер. Они по прежнему выпускают cd, зачем им > делать второй мастер для online? Им как раз проще выложить 44.1. Затем что нынче большинство покупок уже совершается онлайн. А сидюки как формат распостранения околели. И хомяки сейчас любят уже 24/192, lossless. Маркетологи сказали что это рулит. Да и продажи флешпамяти надо двигать :) > Если взять 44.1 и сжать opus - получаешь 48. Но если сделать opusdec - получаешь 44.1 По всем признакам эта проблема самоустраняется силами маркетологов и сторов ;) > Потому, что все музыка в нем. Продаваны уже решили что вся музыка должна быть 24/192. Ну как видео - менее 4K - уже не человек^W монитор/телевизор :P. Студии построятся, так же как производители панелей и контента. Денег всем хочется. А обладатели плееров вообще онлайн с своих железок не лазят и поэтому денег с них не получишь. > На PC да - стандарт. А вот в мобильном сегменте - не факт. Описание блоков на которые я натыкался обычно гласили про 48кГц или кратные. > Нет, как я уже сказал, это элементарно делает современный (5-10 лет) CGU. У большинства систем аудио таки не цель существования системы а всего лишь одна из 100500 фич и вешать каждой фиче по жирному специализированному блоку - накладно слишком. Такое только в спец-SoC для плееров наверное. Может иногда и где-то еще бывает. Но обычно есть целые делители и иногда PLL для умножения. При том PLL - нишевые штуки со своими особенностями. > и поставит. Раньше на дорогих платах ставили отдельные два кварца и > переключались между ними - точность выше (кварцы с повышенной точностью) но > относительно сложно и дорого. Не знаю про какие платы речь, но большинство планшето-смартовых чипов тактируется от одного кварца с какой-нибудь типовой круглой частотой. Сделать из них 48 или даже 192 кГц можно элементарным счетчиком. А вот 44100... > Qualcomm MSM7227A Хм, интересно. Надо попробовать поискать даташит, чтоли. > Тут ситуация похожа на jpeg и mp3 - даже если есть что > лучше, особого смысла менять нет и все продолжают использовать. Вот не надо тут за всех расписываться. У меня часть треков в vorbis, что-то в flac, немного даже в opus. А mp3 я считаю глупым и неэффективным форматом, да еще и с патентами. И поэтому избегаю его при наличии альтернатив. Один из самых плохих lossy форматов. А с jpeg - на самом деле альтернативы пытаются сделать давно но у них свои проблемы. Кто патентами обложен как собака блохами, у кого либ вменяемых нет, кто просто неоднозначный и сделан наспех, как webp. > Я это не утверждал. Это как с mmx/sse когда подходит - используем > и ускоряемся, если не - делаем по-старинке на стандартном наборе команд. Ну так то да, но мне больше нравятся generic железки не делающие допущения какой там будет алгоритм. Ну разве что совсем generic допущения, как simd всякий. > Производители SoC с вами не согласны, но это их дело :) Производители узконишевых специализированных SoC. Которые капля в море полупроводниковой промышленности. В большинстве SoC ничего такого нет. Техас вон тоже думал что их сигнальники встроенные в omap - преимущество. А на них все взяли и забили. > Я же лично хотел бы "вечный" плеер с зарядом от нажатия клавиш > при использовании и весом в 20-30г. Подозреваю что в нажатии клавиш недостаточно энергии. Физику не обманешь: в сами уши улетают какие-то доли ватта, кнопками это напряжненько. Вообще, пока такие уровни энергии проще всего снять или с солнечной батареи или с пельтье, подогреваемого таки приличнее чем температура тела человека. В плеере можно попробовать пристроить какой-нибудь магнитный маятник, наводящий ЭДС в катушке. Накрайняк если тряски от ходьбы не хватит, потряс специально - подзарядил. Жаль что для автономных датчиков не катит - они чаще всего неподвижны. Хотя... хотя мне кажется что я придумал пару прикольных вещиц где номер прокатит. > Для этого и нужны серьезные оптимизации. Я не думаю что вы с кнопок снимете достаточно хотя-бы для энергии в уши без превращения плеера в тренажер. > Пока при таком весе и 20-30 часов не каждый плеер осилит. Хм, получается что смарт почти столько же играет - за счет более жирной батарейки. Габариты у него конечно не плеерные, но он обычно со мной. > Нет ;) Я про ваш смарт ;)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	132. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 17-Ноя-16, 14:19
	> Я думаю что это нормально чтобы слушать музыку на том же мобильном > устройстве например. Где место может быть ограничено, а колонки на ушах > могут быть непрактичны. И для аудио книг - там самые популярные битрейты - mp3/64-128, качество не особо критично, а сами книги более 30 часов бывают. > В идеале слепым тестом и на разных кодеках, но это уж как > ресурсы позволят. Да, хочу проверить на каких битрейтах (для mp3 и opus) определение сжатого трека станет неуверенным. > ИМХО опусом на 96-128 можно заменить мп3 на 256 и выше, поэтому > я его считаю ближе к двукратной разнице. У опус вроде упор оптимизации был на низкие битрейты. Нужно сравнивать. >> ИМХО все равно много. Явно плохо оптимизирован - динамика на clip zip >> 3-5 мА и это с его древним cpu. > У него все-таки этот ваш хардварный блок и система менее разлапистая. Нет, у clip zip только ARM926EJS, так что декодирование полностью программное. > Видео все-таки для движущихся картинок. Кодек имеет полное право использовать эффект temporal > masking для экономии битрейта. Так он и использует. Просто я не знаю надежной методики, как сравнивать качество на движущихся сценах. При обычном просмотре на моих битрейтах оба кодека ведут себя прилично. > А то что это затрагивает стопкадры - > видео все-таки не для публикации фотографий и скриншотов. Конкретно для меня это важно. Основной материал - home video и 3d/2d анимация. Для home video мне самому иногда интересно рассмотреть детали, 3d/2d анимация будет демонстрироваться студентам в качестве примера, да и неподвижных/малоподвижных кадров там много. > А q - квантизатор? Неправильно написал - crf 21-24, то есть постоянное качество. >> Да, но на средних-больших битрейтах эти блоки превращаются в детали. > А я не фанат больших битрейтов. Зачем мне "как xvid", только еще > сильнее грузящий проц? Не, для xvid нужен еще в двое больший битрейт. > Не замечал особо. А титры и тому подобный мелкий текст, где это > хорошо заметно у VP9 так вообще традиционно четче чем в x264 > обычно получается. С вашими квантизаторами такое как вообще выглядит? Вроде это > довольно высокий квантизатор. Не знаю. Но при crf=21 2d/3d анимация (там часто текст анимируется) стопкадры выглядят практически идеально. > Поэтому у меня получалось сдуть файлы с камер > в РАЗЫ при том что я не могу найти дефекты даже > на стопкадрах. А сотни гигз полученные в результате сдувания жирных файлов > на глаз заметны хорошо. Там задача другая - сохранить максимум деталей. Я бы лично хотел еще больший битрейт, так как стоп кадр все равно уступает хорошему jpeg. А далее редактирование и естественно сжатие с качеством зависящим от задачи. > Для x264 я использую самый > медленный пресет - если что-то перекодируется, оно наверное будет храниться долго, > поэтому меня интересует оптимизация битрейт/качество прежде всего. Why is placebo a waste of time? It helps at most ~1% compared to the veryslow preset at the cost of a much higher encoding time. It's diminishing returns: veryslow helps about 3% compared to the slower preset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset. https://trac.ffmpeg.org/wiki/Encode/H.264 На placebo два часа видео (720p) будет жаться примерно двое суток, при выигрыше менее 10%. Электричество дороже обойдется, чем место на винте :) >> Это решения ценой в 0.5$-5$, где качество звука в прямом смысле как у AC97. > Это большинство чипов для смартов и планшетов, встроенное аудио большинства писюков/лаптопов > и проч. Большинство людей слышат через них. Так им все равно, что 44.1, что 48 или 96 - им качество второстепенно. В лучшем случае они будут слушать через средние затычки, а то и вовсе через динамик смарта/ноутбука. >> Любой современный  CGU (clock generation unit) без проблем справляется с этой >> задачей, так как имеет гибкую систему делителей и множителей. > Это некий отдельный узкоспециализированный блок. Его элементарно нет в большинстве железяк. Как нет? ИМХО не один SoC без него не обходится (возможно называется иначе). Сейчас обычно ставят один кварц и от него тактируют все блоки. > Дробные делители и множители для большинства железяк - экзотика. Для SoC - норма. > Например я > без проблем синтезирую 48кГц или деривативы таймером в STM32 от типовых > кварцев. А вот как 44100 или деривативы там получить - я > хз. Не то чтобы тамошний DAC нацелен на качественное аудио т.к. > 12 битов. Но все-таки. Ну STM32 это все же uC и не предназначен для аудио, но даже на нем - "DAC by setting the clock to TIM_Period to 1088 (48Mhz / 1088 = 44117)". Точность не ахти, но для такого случая более чем достаточно. > А хомякам все-равно сейчас 24/192/lossless подавай. Не забывайте, что есть и второй стандартный ряд - 44.1/88.2/176.4. > Маркетолоки сказали что меньше - не > круто. И поэтому всем будет FullHD'ец :) Говорить они могут много. А вот реально мало кто использует 96 или 192. Ибо если человеку нужно хорошее аудио - он читает и через 5-10 минут узнает, что 96-192 ничего реально не дают. Если ему все равно - то он и не знает, что такое 24/192. >> И много их? 1% или 0.1%? > Учитывая что онлайн продажи перевесили физические носители - годиков через 5 поговорим > чего там 0.1% :) HD audio доступно уже лет 15. Пять лет ничего не изменят. Люди не хотят качать альбомы в гигиабайт-два. MP3/320 и flac/16/44.1 стали фактически стандартами. Да и то flac качают только меломаны. Уверен, что и через 5 лет - MP3/320 существенно не сдаст позиций. > Затем что нынче большинство покупок уже совершается онлайн. А сидюки как формат > распостранения околели. Да но и dat (откуда те самые 48kHz) околел еще ранее :) > И хомяки сейчас любят уже 24/192, lossless. Маркетологи сказали > что это рулит. Да и продажи флешпамяти надо двигать :) Оглянитесь вокруг: все слушают mp3 и даже не знают что такое 24/192. Я знаю четырех людей, у которых основной источник - коллекция винила, в том числе и современного (у двух из них ламповые усилители). Но не знаю никого, кто собирает 24/192. >> Потому, что все музыка в нем. > Продаваны уже решили что вся музыка должна быть 24/192. Ну как видео > - менее 4K - уже не человек^W монитор/телевизор :P. Студии построятся, > так же как производители панелей и контента. Денег всем хочется. А > обладатели плееров вообще онлайн с своих железок не лазят и поэтому > денег с них не получишь. Я могу поверить, что opus приживется в online, но не как не 24/192 с их битрейтами. >> Нет, как я уже сказал, это элементарно делает современный (5-10 лет) CGU. > У большинства систем аудио таки не цель существования системы а всего лишь > одна из 100500 фич и вешать каждой фиче по жирному специализированному > блоку - накладно слишком. Такое только в спец-SoC для плееров наверное. Нет это единый блок для всего SoC. > Может иногда и где-то еще бывает. Но обычно есть целые делители > и иногда PLL для умножения. При том PLL - нишевые штуки > со своими особенностями. Для uC - да. Для SoC PLL и CGU - неотъемлемая часть. >> и поставит. Раньше на дорогих платах ставили отдельные два кварца и >> переключались между ними - точность выше (кварцы с повышенной точностью) но >> относительно сложно и дорого. > Не знаю про какие платы речь, Типа моих emu-1212m и emu-0204. > но большинство планшето-смартовых чипов тактируется от > одного кварца с какой-нибудь типовой круглой частотой. Так и я о том же. Но на SoC куча железа и не факт, что все частоты будут кратными. Ставить отдельные кварцы не выгодно. Ставят один кварц и CGU. Он тактирует железо как угодно. Да и удобно это - так как можно легко отключать/включать блоки и произвольно менять частоты для оптимальной производительности/энергопотребления. >> Qualcomm MSM7227A > Хм, интересно. Надо попробовать поискать даташит, чтоли. Если в плеер с конечной ценой 15-30$ ставят SoC с GCU, то в смарте без него никак. > Вот не надо тут за всех расписываться. Ok, 99.9% пользователей. > А с jpeg - на самом деле альтернативы пытаются сделать давно но > у них свои проблемы. Кто патентами обложен как собака блохами, у > кого либ вменяемых нет, кто просто неоднозначный и сделан наспех, как > webp. С jpeg вообще все печально - уже много лет не действуют патенты и можно свободно использовать его с арифметическим кодированием, но все из-за совместимости продолжают использовать обычный jpeg. > Производители узконишевых специализированных SoC. Которые капля в море полупроводниковой > промышленности. В большинстве SoC ничего такого нет. Техас вон тоже думал > что их сигнальники встроенные в omap - преимущество. А на них > все взяли и забили. Бывает и так. >> Я же лично хотел бы "вечный" плеер с зарядом от нажатия клавиш >> при использовании и весом в 20-30г. > Подозреваю что в нажатии клавиш недостаточно энергии. Физику не обманешь: в сами > уши улетают какие-то доли ватта, Очень не много, в первом приближении их можно вообще не учитывать. > Вообще, пока такие > уровни энергии проще всего снять или с солнечной батареи или с > пельтье, подогреваемого таки приличнее чем температура тела человека. В плеере можно > попробовать пристроить какой-нибудь магнитный маятник, наводящий ЭДС в катушке. Накрайняк > если тряски от ходьбы не хватит, потряс специально - подзарядил. Возможно, это будет и лучше. Или комбинация источников. Но в любом случае нужно работать над потреблением устройства. >> Пока при таком весе и 20-30 часов не каждый плеер осилит. > Хм, получается что смарт почти столько же играет - за счет более > жирной батарейки. Да. Учитывая сколько может работать обычная звонилка, эффективность смарта и в режиме ожидания/разговора также не велика. >> Нет ;) > Я про ваш смарт ;) Ну тогда - да ;) Но даже на нем есть разница в 5-10%.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	139. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 20-Ноя-16, 02:03
	> И для аудио книг Про них я знаю только что они существуют. Мне не понятен пойнт этого формата. Это не мой формат. > Да, хочу проверить на каких битрейтах (для mp3 и opus) определение сжатого трека станет неуверенным. Хорошая идея. Для себя я сделал прикидки, точность понятно какая. > У опус вроде упор оптимизации был на низкие битрейты. Нужно сравнивать. Он по своему уникален - позволяет относительно плавный переход из спич-кодека в обычный. Так вроде никто больше не умеет. > Нет, у clip zip только ARM926EJS, так что декодирование полностью программное. Тогда видимо роялит что система менее разлапистая. > Так он и использует. Просто я не знаю надежной методики, как сравнивать > качество на движущихся сценах. Идеальных метрик как я понимаю нет. Вроде пытаются аппроксимировать учитывая temporal masking как эффект. Но есть ли какие-то готовые метрики на основе этого я не знаю. > При обычном просмотре на моих битрейтах оба кодека ведут себя прилично. А мне нравится иследовать границы возможностей технологий. Движение вперед - это часть инженерии. > анимация будет демонстрироваться студентам в качестве примера, да и неподвижных/ > малоподвижных кадров там много. По моим наблюдениям у vp9 нет особых проблем с такими вещами. Как раз мелкий текст и прочий лайнарт он вроде особо не портит, даже при достаточно агрессивных настройках битрейта. А вот как переубедить x264 не грохать текст в титрах - я так и не придумал особо. Ну то-есть конечно можно битрейт закручивать, но я не понимаю почему это должно требовать столько битов, да и почему я это должен как-то сильно отдельно вручную костылить, даже при 2-pass. > Неправильно написал - crf 21-24, то есть постоянное качество. Этот уже поинтереснее, насколько я понимаю - набор настроек которые я предпочитаю - чем-то похож на CRF по смыслу. С той разницей что я обычно считаю более целесообразным предоставить кодеку самому выбирать квантизатор в пределах бюждета и вместо этого оперировать желаемым битрейтом/размером файла. > Не, для xvid нужен еще в двое больший битрейт. Говоря за себя - я использую VP9 с достаточно агрессивными настройками битрейта (если я что-то пережимаю - то чтобы убавить размер). Но тут стоит сказать что я обычно упражняюсь на более-менее обычных видео, снятых с камерой или как максимум - у меня есть несколько нежатых мувиков и самым синтетическим из того что у меня есть наверноя является Big Buck Bunny и пара скринкастов. > Не знаю. Но при crf=21 2d/3d анимация (там часто текст анимируется) стопкадры > выглядят практически идеально. А тут вопрос в том какой битрейт получается, насколько сильно меняется контент и проч. Грабля которую я заметил - если x264 указать некий желаемый битрейт (чтобы контролировать итоговый размер файла или требования к серверу) и в целом этот битрейт для этого фильмообразеого мувика ОК, убедить x264 прилично себя вести на титрах почти невозможно. Такое ощущение что он не может адаптироваться к резкой смене типа контента или motion compensation не срабатыает. Я не совсем понимаю почему у него титры и т.п. мелкий текст хреново выглядят даже на довольно большом (по сравнению с VP9) битрейте и даже на самых медленных пресетах. VP9 вроде никакого подъема битрейта не требуется и он сам на автомате с таким справляется. Что в принципе не удивительно - гуглу актуален режим "fire and forget". > Там задача другая - сохранить максимум деталей. Я бы лично хотел еще > больший битрейт, так как стоп кадр все равно уступает хорошему jpeg. Для меня задача на видео с камеры обычно чуть иная - сдуть их в разы и сделать играемыми даже на не очень мощных компьютерах. Добрых 50Мбит H.264 - по зубам далеко не любой машине, а некоторые камеры почему-то норовят снять именно так, видимо компенсируя хреновый motion compensation суровым битрейтом. Что на тяжелом кодеке предъявляет очень высокие требования к CPU и занимает уйму места неизвестно ради чего. > А далее редактирование и естественно сжатие с качеством зависящим от задачи. Если редактрование подразумевается - тут да, минимальное сжатие по любому, а в идеале - lossless или прочая нарезка/склейка без рекомпрессии. Иначе будет артефакт на артефакте, жать много раз подряд плохая идея. > It helps at most ~1% compared to the veryslow preset at the > cost of a much higher encoding time. ...и в результате - x264 не может взять высоты VP9, хоть там что. Он продувает явно более чем на 1% по битрейт-качество. По крайней мере на низких-средних битрейтах оно так. А сильно высокие меня как-то и не интересуют обычно если я рекомпрессией занялся, 50 мбитов H.264 - и так навалом :) > 5% compared to the slow preset, and slow helps about 5-10% > compared to the medium preset. Ну и вот в результате я вообще не могу из x264 получить битрейт/качество похожие на VP9. Наверное логично что я считаю VP9 более сильным кодеком в итоге. > На placebo два часа видео (720p) будет жаться примерно двое суток, при > выигрыше менее 10%. Электричество дороже обойдется, чем место на винте :) Тут комплексная проблема. 1) Положить видео на сервак - сервировать 50 Мбит H.264 не прикольно. 2) В отличие от электричества, место жрется постоянно и на любом девайсе. 3) Покупки новых винчей подразумевают ощутимые единоразовые затраты. 4) На количество винчей есть технические лимиты, особенно у ноутов. 5) Тяжелое видео грузит проц, а распоследний core i7 для декодирования H.264 @ 50mpbs есть не у всех и не везде. > Так им все равно, что 44.1, что 48 или 96 - им качество второстепенно. А это кому как. В любом случае их оборудование оперирует 48 (96, 192,...) и отрасль перестроится под них. Как известно, кто платит - тот и заказывает музыку. > В лучшем случае они будут слушать через средние затычки, > а то и вовсе через динамик смарта/ноутбука. Им ничего не мешает купить ну хотя-бы неплохие наушники. А у современных интеграшек параметры в общем-то достаточно приличные. По поводу чего дискретное аудио и позагибалось основательно. > Как нет? ИМХО не один SoC без него не обходится (возможно называется иначе). А это зависит от SoC и периферии. Как-то клоки конечно же формируют, но обычно берут круглый по частоте кварц и из него легко сделать все клоки делением счетчиками и умножением на PLL. > Сейчас обычно ставят один кварц и от него тактируют все блоки. Ну да. Благо большинство периферии от грампластинок-2.0 не унаследованы. Еще у UART скорости дурные, потому что унаследовано от релюшек и телетайпов. Но UART без проблем переживают ошибку до 2% и там это не важно. > Для SoC - норма. SoC - термин вольный, им называется что угодно. И вы подставляетесь, выдавая столь общие заявления. Если это норма для специализированных SoC плеров - ок, может быть. А для остальных это как повезет. > Ну STM32 это все же uC и не предназначен для аудио, Ну как, если DAC есть - подразумевается что им можно пользоваться. Внешний DAC приделать тоже можно, всякие I2S там есть, etc. Но вот формировать именно 44100 (или 22050, или что там у кого) - там все-таки изврат. А 48кГц или деривативы можно идеально точно сделать из многих типовых кварцев. Хоть тех же 12МГц, которые в STM идеально вписываются в работу с usb, и максимальные частоты проца - кратные им зачастую. Некоторые SoC/SBC которые я видел юзали 24МГц клок. Те же яйца, вид в профиль. > to 1088 (48Mhz / 1088 = 44117)". Точность не ахти, но > для такого случая более чем достаточно. Кто понимает зачем ему эти извращения - пусть этим и занимается, имхо. >> А хомякам все-равно сейчас 24/192/lossless подавай. > Не забывайте, что есть и второй стандартный ряд - 44.1/88.2/176.4. Ни разу не видел музыки в 88.2 или 176.4. А с инженерной точки зрения я предпочту развидеть левые битрейты характерные для каких-то цифровых патефонов и оперировать частотами которые легко синтезировать из типовых системных клоков/кварцев. > Говорить они могут много. А вот реально мало кто использует 96 или 192. Онлайн продаванам это все расскажете. И сдуваюищимся магазинам сидюков. Скоро они вообще останутся в том же количестве что и продавцы винила, имхо. Спору нет, кто-то и винил слушает. > Ибо если человеку нужно хорошее аудио - он читает и через 5-10 минут узнает, > что 96-192 ничего реально не дают. Если ему все равно - то он и не знает, > что такое 24/192. С практической точки зрения человек покупает то что есть, хорошо для него работает и удобно в использовании. И треки в 176.2 - я вообще ни разу в жизни не видел. Нет, технически то скроить то можно что угодно. Я даже какие-то 37 с чем-то кГц видал. ЧСХ под внимание попало за кривую редискретизацию. > HD audio доступно уже лет 15. Пять лет ничего не изменят. Тут фокус в том что сидюки померли как формат распостранения а продажи ушли в онлайн. Этого 15 лет назад не было, а так все хорошо, прекрасная маркиза. > Люди не хотят качать альбомы в гигиабайт-два. Не знаю, мувики с ютуба смотрят миллионами, а там гиг - вообще не траффик. Посмотреть пару мувиков на 720p по часу - больше сожрет. > MP3/320 и flac/16/44.1 стали фактически стандартами. Стандартами для кого? Для всяких иррациональных аудиофилов верящих в торсионщину и прочих варезников? Покупатели сидюков - внезапно не приносят основной доход студиям уже, а пираты - в лучшем случае их не замечают. > Да и то flac качают только меломаны. Уверен, что и > через 5 лет - MP3/320 существенно не сдаст позиций. Среди "мыломанов" - возможно. Только они все вместе взятые - ничего не решают. Источниом дохода студий являются не они. И таки глядя на FullHD'ец я думаю что и тут у маркетологов все прокатит. > Оглянитесь вокруг: все слушают mp3 и даже не знают что такое 24/192. Оглянулся. Половина онлайн площадок беззазренно барыжит lossless'ом в упомянутом формате. И как угодно но этот эффект серьезно прогнет отрасль в ту сторону. > Я знаю четырех людей, у которых основной источник - коллекция винила, > в том числе и современного (у двух из них ламповые усилители). Им нравится теплое ламповое шипение винила? Ах, ну да, это же милые сердцу некроманта теплые аналоговые искажения. А на предложения померять THD конструкции - некромант оскорбится? Вон кто-то продает "конденсаторы с прослушки". Не подошли, типа. > Но не знаю никого, кто собирает 24/192. Зато некоторые собирают вкладыши от жвачек. Наверное они от этого сразу поголовно становятся экспертами в полиграфии и специалистами по технологиям производства жевательной резинки. > Я могу поверить, что opus приживется в online, Да он уже прижился - его заимплементили кому не лень и он банально часть спеков webm. > но не как не 24/192 с их битрейтами. А упомянутый прижился у онлайн-продаванов выгодно загоняющих треки хомячкам. И вот эти продаваны сейчас как раз студиям и платят в основном, если что. И всем хорошо - хомяки получают кр00той трек парой клацев. Продаваны получают сотни профита. Студиям и артистам тоже что-то перепадает. А те кто барыжил сидюками и их форматы - они на излете жизни технологии. > Нет это единый блок для всего SoC. Это на самом деле каждый д... как он хочет. Ну то-есть обычно делают некий мастер-клок и из него так или иначе получают большинство остальных клоков. А как именно это будет сделано - да на это никаких единых типовых подходов нет. И я с наскока привел вполне широко распостраненных STM32 где 44100 - не доставляет. Поэтому пусть там это как-нибудь аудиофилы со своими радиолампами используют, имхо. А где они будут лет через 5 брать контент - уй, не знаю, не мои проблемы. > Для uC - да. Для SoC PLL и CGU - неотъемлемая часть. Опять же - термин SoC очень generic и может включать в себя очень разные вещи. И вот так огульно расписываться за всех - дохлый номер. > Типа моих emu-1212m и emu-0204. А, понятно. Правда не совсем понимаю при чем они тут, все-таки нишевые железки. > выгодно. Ставят один кварц и CGU. Он тактирует железо как угодно. Совершенно не обязательно. Могут ориентироваться на один номинал кварца и под него все подогнать. Большинство скоростных и-фейсов используют круглые частоты, да и i2c/spi всякие обычно тоже. UART - терпит до 2% ошибку и ее там никому не слышно. Никаких стандартов и регламентов как генерить клоки - нет. И как видите я навскидку нашел целый популярный выводок МК где с 44100 - "не очень". > Да и удобно это - так как можно легко отключать/включать блоки > и произвольно менять частоты для оптимальной производительности/энергопотребления. Включение и выключение блоков делается, пардон, силовыми полевиками встроенными в цепь питания блока. Кто и откуда ими командует - совершенно отдельный вопрос. Это делается в меру дурости разработчиков SoC. Гейтование клоков - аналогично. Это может быть и отдельный юнит, и куча регистров в разных местах и что там кому удобнее. > Если в плеер с конечной ценой 15-30$ ставят SoC с GCU, то в смарте без него никак. В плеере SoC посвящен своей задаче целиком и полностью. А для смарта проигрывание аудио - это одна из туевой кучи функций. И кстати парочка из allwinner + чип power manager ему внагрузку может стоить менее $5, все остальное там вообще копейки при массовых тиражах. А в смартах - в смартах некоторые компании делают сверхприбыли. Даже в самом крутом ифоне железа реально спасибо если баксов на 150, при том дороже всего IIRC стоит высококачественный LCD. Все что сверх этой цифры - чистейшая маржа той или иной цепочки продаванов. > Ok, 99.9% пользователей. Ок, как эти проценты посчитаны? :) > и можно свободно использовать его с арифметическим кодированием, но все из-за > совместимости продолжают использовать обычный jpeg. В конечном итоге с арифметическим кодированием жлобы таки довы...сь до того до чего и должны были. Слыхали что-нибудь про ANS? Ну и далее - сделанный на основе этого FSE (Finite State Entropy). Из интересного - хорошие реализации FSE ухитряются сочетать скорость работы а-ля huffman с точностью (и стало быть степенью сжатия) характерной для арифметического кодирования. Придумал это некий Jarek Duda, опубликовавший весьма нетривиальный в чтении paper. Он же помогал Yann Colett'у запилить это в практическую скоростную реализацию. И сейчас как минимум: 1) Zstd (и apple FSE, но кому оно надо если Zstd его рвет) - это FSE+HUF+LZ. 2) В VP10 (и AV1) entropy coding - IIRC тоже на чем-то типа FSE основан. Хотя в AV1 все сложнее т.к. там части из Daala включили и в Daala был какой-то свой EC, но как я понял мастер-план подразумевает все-таки кодинг энтропии на основе изобретения Jarek-а. Т.е. в принципе декодирование может оказаться довольно быстрым. Приветы ресурсожоркому CABAC'у. Поэтому саботаж как ни странно внезапно привел к инженерному прорыву, когда спецы придумали алгоритм который и лучше по сочетанию параметров и патенты не нарушает. И я так считаю что будущее будет вокруг технологий Jarek'а. А арифметики - да кому они теперь нужны? Хоть с патентами, хоть без. В общем всем этим экспертам из ISO имхо придется учиться заниматься разведением рассады. Наконец то впихивание патентованых технологий оптом в свои стандарты им отольется. > Бывает и так. При том довольно часто. Сильно специализированные блоки вообще вещицы на любителей. Компьютеры всем нравятся за то что они generic и перепрограммируемые. >> уши улетают какие-то доли ватта, > Очень не много, в первом приближении их можно вообще не учитывать. Это имхо довольно много по сравнению с тем что светит снять с обычных по восприятию пользователями кнопок мелкого гаджета когда он валяется в кармане. > Возможно, это будет и лучше. Или комбинация источников. Но в любом случае > нужно работать над потреблением устройства. Мне в STM'ках попроще с потреблением, но вот если датчик никто не освещает, не трясет и даже нет источника вибрации или нагрева - сделать его вечным уже заметно сложнее. А хотелось бы :) > Да. Учитывая сколько может работать обычная звонилка, эффективность смарта и в режиме > ожидания/разговора также не велика. Если активна сотовая сеть - смарт периодически должен перерегиваться в сети. В GSM этот период обычно выставляют порядка 2 часов, но вообще это параметр который сеть диктует. А стрелять передатчиком в эфир - это энергоемко (в GSM - до 2W в импульсе, что обеспечивает короткие и злые импульсы токов под пару ампер по всему питанию). > Ну тогда - да ;) Но даже на нем есть разница в 5-10%. У меня так вообще почему-то vorbis чуть экономичнее но в целом - что так 50-55 ма, что эдак. Разница в пределах 10%, что с учетом импульсных процессов где-то в пределах погрешностей.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	142. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 20-Ноя-16, 16:50
	>> Так им все равно, что 44.1, что 48 или 96 - им качество второстепенно. > А это кому как. В любом случае их оборудование оперирует 48 (96, > 192,...) и отрасль перестроится под них. Как известно, кто платит - > тот и заказывает музыку. В том и дело, что проблема поддержки двух частот была примерно до 2005-2010. Сейчас это стоит копейки или вообще ничего. На ali готовый USB-DAC PCM2704 стоит от 4.5$, умеет 32, 44.1 и 48. Кварц - 12 MHz. И обратите внимание - в datasheet все параметры приводятся именно для 44.1. >> Как нет? ИМХО не один SoC без него не обходится (возможно называется иначе). > А это зависит от SoC и периферии. Как-то клоки конечно же формируют, > но обычно берут круглый по частоте кварц и из него легко > сделать все клоки делением счетчиками и умножением на PLL. Так и я о том же - сейчас везде один кварц и гибкая система делителей множителей. > А с инженерной > точки зрения я предпочту развидеть левые битрейты характерные для каких-то цифровых > патефонов и оперировать частотами которые легко синтезировать из типовых системных клоков/кварцев. С одной стороны -  вы говорите, что cd устарел. С другой вы цепляться за древнее железо, которое умеет только кратное умножение/деление частоты кварца. >> Говорить они могут много. А вот реально мало кто использует 96 или 192. > Онлайн продаванам это все расскажете. Так что там народ в основном покупает? mp3 или 192? > И сдуваюищимся магазинам сидюков. Скоро они вообще > останутся в том же количестве что и продавцы винила, имхо. Спору > нет, кто-то и винил слушает. C 192 будет также как и с super audio cd и dvd audio - их будет слушать столько же людей, сколько слушает винил. Продавцы просто придумали цифровой винил, но массово он не приживется, так как не имеет реальных преимуществ, но имеет кучу недостатков - меньше поддержка, большой размер, много ест (в разы больше) батарейки при декодировании. Я проводил замеры - плеер ест пропорционально частоте воспроизведения. 48 есть на 9% больше, чем 44.1. Можете прикинуть что будет для 192. А если еще и битность удвоить - то получим потребление почти на порядок больше. Учитывая, что музыку слушают в основном с портатива - участь 192/24 решена. >> Люди не хотят качать альбомы в гигиабайт-два. > Не знаю, мувики с ютуба смотрят миллионами, а там гиг - вообще > не траффик. Посмотреть пару мувиков на 720p по часу - больше > сожрет. Вы же не давно говорили, что без opus'а никак ;) Одно дело видео - люди знают, что меньше при нормальном качестве нет. Даже flac и тот мало кто использует - все прагматично говорят - mp3 в четыре раза меньше, а разницы не слышно, тем более на портативе, да на улице/транспорте. Представляю их энтузиазм в отношении 192/24 ... >> MP3/320 и flac/16/44.1 стали фактически стандартами. > Стандартами для кого? Для всяких иррациональных аудиофилов верящих в торсионщину и прочих > варезников? А в каком по-вашему формате в основном все качают с online магазинов? > Им нравится теплое ламповое шипение винила? Ах, ну да, это же милые > сердцу некроманта теплые аналоговые искажения. А на предложения померять THD конструкции > - некромант оскорбится? Там не все так просто. Я и сам раньше строил ламповые усилители и слушал чужие. THD/IMD измеряют и на лампах, но смотрят не %, а графики. При THD в 1-2% ламповый усилок может звучать лучше, чем микросхема с 0.01%. Если в двух словах - % THD имеет смысл только при сходной схемотехнике. Отчасти поэтому я и взялся писать аналог rmaa, так как есть более адекватные (ближе к восприятию человеком) методики измерения. >> Но не знаю никого, кто собирает 24/192. > Зато некоторые собирают вкладыши от жвачек. Наверное они от этого сразу поголовно > становятся экспертами в полиграфии и специалистами по технологиям производства жевательной > резинки. В данном контексте, я не знаю потребителей вкладышей и жвачек. При чем здесь их производство? > И я с наскока привел > вполне широко распостраненных STM32 где 44100 - не доставляет. Почему? Пример я привел - делители/множители для этого есть. Точнсть не high end, но выше чем у обычного кварца и уж более чем достаточная для аудио. >> Типа моих emu-1212m и emu-0204. > А, понятно. Правда не совсем понимаю при чем они тут, все-таки нишевые > железки. Просто пример качественных железок, где особо не экономили. >> выгодно. Ставят один кварц и CGU. Он тактирует железо как угодно. > И как видите я навскидку нашел целый популярный выводок > МК где с 44100 - "не очень". Обоснуйте. И покажите современный soc с аудио dac, где нет гибкой системы множителей/делителей. >> Да и удобно это - так как можно легко отключать/включать блоки >> и произвольно менять частоты для оптимальной производительности/энергопотребления. > Включение и выключение блоков делается, пардон, силовыми полевиками встроенными в цепь > питания блока. Если полностью - то да. Если нужно отключить не сбрасывая внутреннее состояние - то просто гасится clock. > Это имхо довольно много по сравнению с тем что светит снять с > обычных по восприятию пользователями кнопок мелкого гаджета когда он валяется в > кармане. Да, но основная проблема потребление самого SoC. >> Да. Учитывая сколько может работать обычная звонилка, эффективность смарта и в режиме >> ожидания/разговора также не велика. > Если активна сотовая сеть - смарт периодически должен перерегиваться в сети. В > GSM этот период обычно выставляют порядка 2 часов, но вообще это > параметр который сеть диктует. А стрелять передатчиком в эфир - это > энергоемко (в GSM - до 2W в импульсе, что обеспечивает короткие > и злые импульсы токов под пару ампер по всему питанию). Да, но эти импульсы есть и в звонилке, что не мешает ее работать существенно дольше.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	151. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 23-Ноя-16, 12:53
	> Сейчас это стоит копейки или вообще ничего. Аудио-блоки многих планшетных/мобилочных и т.п. SoC делаются как я понимаю на основе блока HDA, и для них нативны все те же 48кГц. > На ali готовый USB-DAC PCM2704 стоит от 4.5$, умеет 32, 44.1 и > 48. Кварц - 12 MHz. И обратите внимание - в datasheet > все параметры приводятся именно для 44.1. Я рад за китайский usb-dac, но когда на том же ali весь одноплатник за 7 баксов лежит - на фоне этого 4.5 бакса за только звук - не выглядят копейками. И опять же - кивать на сильно специализированные чипы - когда чип посвящен задаче, в него могут и специализированный блок сунуть. В чипе где уже есть цать блоков - еще один навороченный блок увеличивает и удорожает чип. В специализированных чипах проблема не стоит - делать чипы меньше энного размера смысла нет, а кроме специфичных для задачи блоков там и нет ничего. > Так и я о том же - сейчас везде один кварц и гибкая система делителей множителей. Вот так огульно расписываться за всех - это здорово, конечно, но мне кажется что это не работает. > С одной стороны -  вы говорите, что cd устарел. С другой вы цепляться > за древнее железо, которое умеет только кратное умножение/деление частоты кварца. STM32 например ни в одном глазу не древний. Особенно если сравнивать его возраст с CD. > Так что там народ в основном покупает? mp3 или 192? Я к тому что в качестве источника не испорченной сжатием музыки со временем будет вот это. > C 192 будет также как и с super audio cd и dvd audio - их будет слушать > столько же людей, сколько слушает винил. Я думаю что их будут слушать почти все кто хотел аудио более качественное чем lossy. Просто потому что сидюки скоро станут чем-то типа винила. > как не имеет реальных преимуществ, но имеет кучу недостатков - меньше > поддержка, большой размер, много ест (в разы больше) батарейки при декодировании. Такой формат имеет смысл если хочется звук без артефактов сжатия. Понятно что это надо не всем. Просто сидюки сдохли как формат и на замену у студий видимо будет вот это. > Я проводил замеры - плеер ест пропорционально частоте воспроизведения. Это в принципе логично. > 48 есть на 9% больше, чем 44.1. Можете прикинуть что будет для 192. Я не думаю что такой формат имеет очень большой смысл для мобильных устройств. Но сидюки утратили смысл почти везде - вот это видимо их и заменит. > А если еще и битность удвоить - то получим потребление почти на порядок больше. Звучит страшно, только на фоне общего потребления системы в смартах и т.п. соотношения выйдут имхо значительно менее ужасные. На порядок увеличится потребление 1 блока. Из пары дюжин. А в целом - будет процентов на 10, ну может 20 больше для большинства generic устройств. Плеерам может и напряг, но это весьма нишевые проблемы. Смартфоны с своими батарейками на 2 амперчаса это просто не заметят. > Учитывая, что музыку слушают в основном с портатива - участь 192/24 решена. Я думаю что его участь - заменить сидюки как формат распостранения с качеством выше lossy. > Вы же не давно говорили, что без opus'а никак ;) Ну да. Просто случаи бывают разные. И если кто-то таки хочет трек в максимальном качестве, даже если это компромисс в чем-то другом - почему нет? То что мне нравится степень сжатия VP9 - не мешает мне содержать несколько несжатых тестовых мувиков, хоть они и занимают много места. А по другому тестирование кодека будет необъективным, вот и. > Одно дело видео - люди знают, что меньше при нормальном качестве нет. Аудио и видео по сути отличаются тем что одно в 1D, а другое 2D. В остальном эти области достаточно похожи. Поэтому я не вижу предпосылок применять фундаментально разные подходы. Разве что с той разницей что lossless аудио менее напряжно по размеру. Для видео даже бывают lossless кодеки. > на портативе, да на улице/транспорте. Ну тогда opus-ом и в 6-8 раз меньше можно сделать, чтоли, если уж размер интересовал :P. > Представляю их энтузиазм в отношении 192/24 ... Это скорее онлайн-замена сидюкам как формату распостранения. Слушать это на затычки в автобусе будет странной идеей. Но в конце концов, CD-плееры же были. Хоть и отвратные по юзабилити девайсы. > А в каком по-вашему формате в основном все качают с online магазинов? Да кто как вроде. Эппл одно время любил AAC и какой-то свой lossless формат. Разлюбили ли они это - а пусть яблочники скажут. >> А на предложения померять THD конструкции - некромант оскорбится? > Там не все так просто. Конечно. Люди очень забагованные и иррациональные существа, пытающиеся нахваливать свое болото при удобном случае и игнорируя технические метрики и объективные данные. Слепые тесты нужны в т.ч. и из-за этого. > %, а графики. При THD в 1-2% ламповый усилок может звучать лучше, чем микросхема с 0.01%. Что я о людских багах говорил? :) Такие заявления надо проверять слепыми тестами и на толпе народа, для сбора статистики. И давать научное объяснение эффекту. Это кто-то делал? > Если в двух словах - % THD имеет смысл только при сходной схемотехнике. Откуда это следует? Хоть аналог и не мой люимый раздел схемотехники, но я неплохо знаю физику в области электричества и магнетизма. И поэтому могу оперировать произвольным описанием процессов в любых цепях. Поэтому тезис что один THD чем-то лучше другого - неплохо бы научно обосновать. А еще интересно - чего аудиофилы от SMPS шарахаются? С точки зрения физики и схемотехники зафильтровать 100-500кГц сильно проще чем 50Гц. Я что-то упускаю? > Отчасти поэтому я и взялся писать аналог rmaa, так как есть более адекватные > (ближе к восприятию человеком) методики измерения. А они имеют под собой научное обоснование? Ну и говоря за себя - мне могут быть интересны и формальные метрики. А хотя-бы из соображений использования девайсов для генерации и исследования сигналов. ИМХО, объективные технические параметры железки - одно, а психоакустические дела и особенности человека - другое. > В данном контексте, я не знаю потребителей вкладышей и жвачек. При чем здесь их производство? Это я намекал что если кто-то собирает вкладыши - это еще ничего не доказывает. То же самое и с форматами. > Почему? Пример я привел - делители/множители для этого есть. Точнсть не high > end, но выше чем у обычного кварца У обычных кварцев точность в хучшем случае заявляется 100ppm. Зачастую так вообще 50. Если что, 50ppm = 2.21 Гц ошибки @ 44110. > и уж более чем достаточная для аудио. Тем не менее, я как-то не фанат таких костылей. Поэтому с инженерной точки зрения пожелаю столь левым частотам скорейшей кончины. > Просто пример качественных железок, где особо не экономили. Ну хорошо, я рад за них. Но это никого ни к чему не обязывает. > Обоснуйте. И покажите современный soc с аудио dac, где нет гибкой системы > множителей/делителей. Я вроде уже показал вполне обыденный STM32. У него даже DAC встроенный есть, хоть и не аудиофильский. >> Включение и выключение блоков делается, пардон, силовыми полевиками... > Если полностью - то да. Ну так в целом есть два отдельных действия - "power gating" и "clock gating". Первый кардинальнее и приводит потребление блока к нулю, устраняя всякие статичные утечки и проч. Clock gating менее эффективен - статические утечки остаются, но динамические потери устраняются. > Если нужно отключить не сбрасывая внутреннее состояние - то просто гасится clock. Ну да. Только это не выключение блока а всего лишь clock gating. В медленных чипах сделанных по сравнительно дубовым процессам его может и хватить. В больших скоростных чипах сделанных по тонким процессам гейтования клоков недостаточно для получения низкого потребления в idle, поэтому сделали следующий логичный шаг - полноценный power gating. > Да, но основная проблема потребление самого SoC. И это тоже. Но имхо с нажатия кнопок не светит снять даже энергию для наушников, если не превращать девайс в некий тренажер. А если еще какую-нибудь подсветку экрана захотеть - тут уж физику не обманешь: если хочется большой экран и чтобы он еще и светился - извольте энергии вбухать в излучение экраном света. Собственно у штук типа смартов, планшетов и ноутов - основную часть энергии при многих сценариях использования съедает экран. И самый эффективный power save - яркость скостить. И получить тусклую невзрачную картинку, ага. > Да, но эти импульсы есть и в звонилке, что не мешает ее > работать существенно дольше. Тут на самом деле очень зависит от внешних факторов. Если вы звонилку бросите включенной в едущем поезде - нет, месяц ожидания вы там не получите. Сколько будет в чистом поле... эээ а время перерегистрации в сети - это параметр сети. Сколько сеть скажет - столько и будет. Так что может зависеть даже от оператора и локации, не говоря про более прозаичные вещи типа потери сигнала БС и острую нужду перерегаться на другой БС чтобы вызовы не пропустить ;).
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	153. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 23-Ноя-16, 15:18
	> Аудио-блоки многих планшетных/мобилочных и т.п. SoC делаются как я понимаю на основе > блока HDA, и для них нативны все те же 48кГц. Нет. HDA - это отдельный специфический случай, когда на мат плату паяют отдельный кодек, отдельный кварц и цепляют к южному мосту. В SoC просто встраивают DAC, тактируют от общего CGU. Данные идут по общей шине (AMBA) до блока I2S, а с него на DAC. >> На ali готовый USB-DAC PCM2704 стоит от 4.5$, умеет 32, 44.1 и >> 48. Кварц - 12 MHz. И обратите внимание - в datasheet >> все параметры приводятся именно для 44.1. > Я рад за китайский usb-dac, но когда на том же ali весь > одноплатник за 7 баксов лежит - на фоне этого 4.5 бакса > за только звук - не выглядят копейками. И опять же - > кивать на сильно специализированные чипы - когда чип посвящен задаче, в > него могут и специализированный блок сунуть. Я просто показал, что 44.1 и 48 могут стоить относительно дешево и что производители проводят замеры на 44.1, а значит считают их основным режимом. >> А если еще и битность удвоить - то получим потребление почти на порядок больше. > Звучит страшно, только на фоне общего потребления системы в смартах и т.п. > соотношения выйдут имхо значительно менее ужасные. На порядок увеличится потребление 1 > блока. Из пары дюжин. А в целом - будет процентов на > 10, ну может 20 больше для большинства generic устройств. Плеерам может > и напряг, но это весьма нишевые проблемы. Смартфоны с своими батарейками > на 2 амперчаса это просто не заметят. ИМХО - нет. Тут основное потребление - io DAC. Как ни крути, а большой поток данных потребует много энергии. Для смартов может не на порядок, но в разы больше точно. >> Одно дело видео - люди знают, что меньше при нормальном качестве нет. > Аудио и видео по сути отличаются тем что одно в 1D, а > другое 2D. В остальном эти области достаточно похожи. Поэтому я не > вижу предпосылок применять фундаментально разные подходы. Разве что с той разницей > что lossless аудио менее напряжно по размеру. Для видео даже бывают > lossless кодеки. Естественно, но большинство предпочитает сжатые фильмы и музыку. На торрентах по-прежнему наиболее качаемые раздачи фильмов - 1.5-2.5 GB. Это при том, что у них есть возможность качать бесплатно фильмы по 10-60 GB - то есть, оно им даром не надо ;) Тоже и с музыкой. >> А в каком по-вашему формате в основном все качают с online магазинов? > Да кто как вроде. Эппл одно время любил AAC и какой-то свой > lossless формат. Разлюбили ли они это - а пусть яблочники скажут. Apple - это 5-15% рынка. А что с остальными? >> %, а графики. При THD в 1-2% ламповый усилок может звучать лучше, чем микросхема с 0.01%. > Что я о людских багах говорил? :) Такие заявления надо проверять слепыми > тестами и на толпе народа, для сбора статистики. И давать научное > объяснение эффекту. Это кто-то делал? Естественно, если покопать, то найдете много статей и научных исследований. >> Если в двух словах - % THD имеет смысл только при сходной схемотехнике. > Откуда это следует? Хоть аналог и не мой люимый раздел схемотехники, но > я неплохо знаю физику в области электричества и магнетизма. И поэтому > могу оперировать произвольным описанием процессов в любых цепях. Поэтому тезис что > один THD чем-то лучше другого - неплохо бы научно обосновать. Я уже сказал - важны не %, а состав спектра. 1. В ламповой схемотехнике не используют OOC - хвост гармоник ограничивается 3-6. Человек не воспринимает первые гармоники как явные искажения, так как они присутствуют практически во всех натуральных звуках. Более того, многим нравится подобный "улучшайзер" - звук богаче, более насыщенный. Посей день многие музыканты используют ламповые предусилители в студиях для микрофонов и гитар. Длинный хвост спектра характерен для схем с глубокой ООС. Он наоборот звучит инородно и делает звучание более жестким. Самый длинный хвост возникает при клиппинге - думаю вы знаете как противно он звучит. 2. Соотношение четных и нечетных гармоник. Четные гармоники более предпочтительны, чем нечетные. Именно такой спектр выдают ламповые усилители. > А еще интересно - чего аудиофилы от SMPS шарахаются? С точки зрения > физики и схемотехники зафильтровать 100-500кГц сильно проще чем 50Гц. Я что-то > упускаю? 100-500кГц очень хорошо расползаются по всему аудиотракту и вылазят в самых неожиданных местах звукового спектра. По этом в первом приближении 50 (и гармоники 100-150) Гц более безопасны и легче в диагностике. Но грамотно построенный и экранированный импульсник не должен создавать существенных проблем. Другое дело, что накасячить с ним легко, отсюда и дурная слава. В портативе еще интереснее: например у SoC clip zip (с заявками на хороший звук) основной источник - импульсный, но вся аналоговая аудио часть питается от LDO. Вероятно полностью отфильтровать импульсный источник при таких размерах проблемно. >Ну и говоря за себя > - мне могут быть интересны и формальные метрики. А хотя-бы из > соображений использования девайсов для генерации и исследования сигналов. ИМХО, объективные > технические параметры железки - одно, а психоакустические дела и особенности человека > - другое. В том и дело, что для аудио важна психоаккустика. Ведь задача - звук для человеческого уха, а не для спектрометра. И тут важно понимать в каких случаях измеренные параметры имеют отношение к качеству звучания, а в каких это чистый маркетинг. >> и уж более чем достаточная для аудио. > Тем не менее, я как-то не фанат таких костылей. Поэтому с инженерной > точки зрения пожелаю столь левым частотам скорейшей кончины. Почему это костыли? Почему STM32 содержит эти костыли? Чем плохо с именно с инженерной точки зрения? >> Обоснуйте. И покажите современный soc с аудио dac, где нет гибкой системы >> множителей/делителей. > Я вроде уже показал вполне обыденный STM32. У него даже DAC встроенный > есть, хоть и не аудиофильский. Нет. Не вижу реальных обоснований, кроме того, что вы лично не любите не круглые частоты. И еще раз STM32 не SoC. И dac 12 бит - это даже AC97 не снилось, даже 20 лет назад для аудио массово выпускали DAC с реальными 14 битами, не говоря уж о современных требованиях. >> Да, но эти импульсы есть и в звонилке, что не мешает ее >> работать существенно дольше. > Тут на самом деле очень зависит от внешних факторов. Если вы звонилку > бросите включенной в едущем поезде - нет, месяц ожидания вы там > не получите. Естественно, но при прочих равных потребление смарта существенно выше.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	154. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 26-Ноя-16, 06:49
	> плату паяют отдельный кодек, отдельный кварц ЧСХ на кварце часто экономят ;) > и цепляют к южному мосту. А в SOC - цепляют IP-блок на внутреннюю шину. С клоками та же история, но воткнуть несколько PLL и счетчиков можно и без лицензирования. А можно купить или разработать что-то покруче. По желанию. > В SoC просто встраивают DAC, тактируют от общего CGU. В плеерных - может быть. В general purpose - см. выше. > Данные идут по общей шине (AMBA) до блока I2S, а с него на DAC. ARM - "Lego для чипмейкеров", полагать что какой-то кирпичик кроме процессорного ядра и еще по мелочи mandatoty - фигвам. > Я просто показал, что 44.1 и 48 могут стоить относительно дешево и > что производители проводят замеры на 44.1, а значит считают их основным режимом. Производители специализированных штук типа usb-dac? Возможно. У них целый пустой кристалл который можно занять чем угодно. А в SoC общего назначения - кристалл предпочитают тратить на максимизацию производительности. > а большой поток данных потребует много энергии. Для смартов может не > на порядок, но в разы больше точно. Хызы, это мерять надо, имхо. При случае попробую такое на нокии. Но насколько я понял, нативно для железа там 48000. А как посмотреть возможности "типа звуковухи" в урезанном окружении? Тем же aplay поиграться не получается: вывод только через пульс, пульс согласен на любое до 192000, но он ресэмплит на автомате. > Естественно, но большинство предпочитает сжатые фильмы и музыку. Нежатые фильмы до сих пор сложно предпочитать :P. > На торрентах по-прежнему наиболее качаемые раздачи фильмов - 1.5-2.5 GB. Качать 30 гигз чтобы узнать что это очередная конвейерная штамповка - на любителя. > Это при том, что у них есть возможность качать бесплатно фильмы по 10-60 GB - > то есть, оно им даром не надо ;) Тоже и с музыкой. Это скорее на случай если трек понравился и захотелось его в максимальном качестве. > Apple - это 5-15% рынка. А что с остальными? А остальной часто слушают вообще видео на ютубе. > Я уже сказал - важны не %, а состав спектра. Если с точки зрения психоакустики - может быть. > ламповые предусилители в студиях для микрофонов и гитар. У гитаристов звук и сам по себе должен быть с гармониками - струны же. Ну и вообще эффекты имхо лучше в софте. В железе они неустранимы и не переконфигурируемы. > Длинный хвост спектра характерен для схем с глубокой ООС. ООС как я понимаю делают чтобы схема вела себя прилично. Иначе импульсный отклик будет жуткий, а при единице усилитель превращается в генератор. Это вроде не должно быть специфично для именно полупроводников. В каком месте наступает профит? На первый взгляд чипмейкеры вообще имеют фору: у них все масштабы микроскопические, те же наводки на микроны или сантиметры провода - отличия на порядки. > Он наоборот звучит инородно и делает звучание более жестким. Это то понятно, да и полупроводники изначально нелинейны. Но сейчас их научились прилично костылить. И прокостылить нежелательные эффекты в чипе имхо проще чем в огроменной фигне, где все паразитные параметры многократно выше. Тут начинаются отмазки про "другие" искажения. Мне с инженерной точки зрения это не нравится. > Самый длинный хвост возникает при клиппинге - думаю вы знаете как противно он звучит. Да, clipping редкая дрянь. > Именно такой спектр выдают ламповые усилители. ИМХО, предпочтителен оригинальный сигнал. А если его звучание кому-то не нравится - это уже к сигналу вопросы, имхо. > 100-500кГц очень хорошо расползаются по всему аудиотракту Зато давится мелкими L и С. А 50Гц L и C можно зашибить. Если экономить - китайцы экономят на кондерах и обмотках 50Гц транса. Такой транс на верхушке синусоиды не удерживает сетево (L недостаточно). Проскакивает сквозной пик тока, dI/dt высокий -> мощная ЭМ волна. > По этом в первом приближении 50 (и гармоники 100-150) Гц более безопасны > и легче в диагностике. Я бы сказал что они вездесссущи и устранять их трудно, дорого и габаритно. > Но грамотно построенный и экранированный импульсник не должен создавать > существенных проблем. Другое дело, что накасячить с ним легко, отсюда и дурная слава. На самом деле 500кГц лучше излучаются. ИМХО LC-фильтры и экран все придавят. > основной источник - импульсный, но вся аналоговая аудио часть питается от LDO. На мамках/звуковухах тоже LDO обычно есть. См. ниже. > Вероятно полностью отфильтровать импульсный источник при таких размерах проблемно. Цифра гадит по питанию: переключения вентилей = перезаряд емкостей. Летят короткие мощные всплески, аналогу не подарок. У STMов - аналоговый Vcc и земля отдельные, чтобы можно было фильтрануть от цифры. Иначе про точность аналога можно забыть. LDO все-равно, он и пульсации импульсника сгладит, если были, и всплески от цифры. Кст, LDO - усилитель, его импульсный отклик не идеален. А если не читать даташит - можно сделать LDO генератором даже. > звук для человеческого уха, а не для спектрометра. ИМХО задачу следует декомпозировать. Дело железок - передать сигнал "как было". А (психо)акустикой нехай занимаются музыканты, звукорежи и кто там еще. Не железкино это дело - приукрасами заниматься. > И тут важно понимать в каких случаях измеренные параметры имеют отношение > к качеству звучания, а в каких это чистый маркетинг. Говоря за себя - я рассматриваю ADC и DAC как ADC и DAC. Приукрасы от таковых мне не требуются. Если композиция плохо звучит на идеальном DAC и усилителе - это недостаток композиции, очевидно. > Почему STM32 содержит эти костыли? Чем плохо с именно с инженерной точки зрения? STM32 не содержит CGU. А костыли - потому что получается какая-то кривая частота с ошибкой. > Не вижу реальных обоснований, кроме того, что вы лично не любите не круглые частоты. Я не люблю кривые инженерные решения, особенно когда единственным аргументом "за" является "мы так привыкли". Сразу вспоминается тот эксперимент с обезьянами, водой и бананами. > не говоря уж о современных требованиях. Если принципиально - DAC можно и внешний прицепить. Но с синтезом времянок все-равно будет то же самое. > Естественно, но при прочих равных потребление смарта существенно выше. А это от условий зависит, имхо. В поезде они наверное помрут за сравнимое время, высадив всю энергию в антенну.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	155. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 26-Ноя-16, 14:12
	> А в SOC - цепляют IP-блок на внутреннюю шину. С клоками та > же история, но воткнуть несколько PLL и счетчиков можно и без > лицензирования. А можно купить или разработать что-то покруче. По желанию. >> В SoC просто встраивают DAC, тактируют от общего CGU. > В плеерных - может быть. В general purpose - см. выше. Так CGU это и есть блок тактирующий остальные - называться он может иначе. Есть даже на AVR - там его зовут AVR Clock Control Unit (http://d.jcole.us/blog/files/avr-clock-distribution-small.png). Он конечно проще чем у SoC, но тем не менее есть. >> Данные идут по общей шине (AMBA) до блока I2S, а с него на DAC. > ARM - "Lego для чипмейкеров", полагать что какой-то кирпичик кроме процессорного ядра > и еще по мелочи mandatoty - фигвам. Правильно, но все кирпичики нужно зацепить вместе. Отсюда общая шина и I2S, так как он часто используется для DAC. Проще взять готовый кирпич, чем изобретать его заново. > А в SoC общего назначения - > кристалл предпочитают тратить на максимизацию производительности. Да, но как я уже отметил - у них поддержка множества частот получается автоматом. >> а большой поток данных потребует много энергии. Для смартов может не >> на порядок, но в разы больше точно. > Хызы, это мерять надо, имхо. При случае попробую такое на нокии. Но > насколько я понял, нативно для железа там 48000. А как посмотреть > возможности "типа звуковухи" в урезанном окружении? Тем же aplay поиграться не > получается: вывод только через пульс, пульс согласен на любое до 192000, > но он ресэмплит на автомате. Как это? Убить PA и запустить вывод напрямую hw:0,0 (без dmix и прочего). Вообще можно глянуть в аудио драйвере - там обычно расписаны все аппаратно поддерживаемые частоты и форматы. P.S. Было бы интересно узнать сколько будет потреблять mp3/wav при прямом выводе. Возможна одна из причин жора смартов - жирный аудио сервер. >> Естественно, но большинство предпочитает сжатые фильмы и музыку. > Нежатые фильмы до сих пор сложно предпочитать :P. :) > А остальной часто слушают вообще видео на ютубе. Сейчас вроде мода прямо с соц сетей слушать, но что там и как не знаю - асоциальный я тип :) >> ламповые предусилители в студиях для микрофонов и гитар. > У гитаристов звук и сам по себе должен быть с гармониками - > струны же. Ну и вообще эффекты имхо лучше в софте. В > железе они неустранимы и не переконфигурируемы. В железе многие вещи получаются проще и автоматом. Попробуйте поиграть на софтовой гитаре :) Нужен и софт и железо - одно другого не заменит. >> Длинный хвост спектра характерен для схем с глубокой ООС. > ООС как я понимаю делают чтобы схема вела себя прилично. Иначе импульсный > отклик будет жуткий, а при единице усилитель превращается в генератор. Это > вроде не должно быть специфично для именно полупроводников. В каком месте > наступает профит? Мощные полупроводники имеют относительно низкие частоты и нуждаются в ООС для расширения частотного диапазона. Смотрите график Gain vs Freq для ОУ. Например классические ОУ lm833 - 20-30 Hz при минимальной ООС. Относительно дорогой (цена производителя 3$ при партии от 100 шт) и быстрый имеет 8-10 kHz. > На первый взгляд чипмейкеры вообще имеют фору: у них > все масштабы микроскопические, те же наводки на микроны или сантиметры провода > - отличия на порядки. Да. В добавок лампе нужен выходной трансформатор для согласования с нагрузкой - что является самой большой проблемой для всех ламповых усилителей. Но есть и свои плюсы - лампе не нужно охлаждение, она выдерживает существенные перегрузки по току - анод может раскалится до красна. Такой режим сокращает жизнь лампе, но звучит он в нем еще лучше. >> Он наоборот звучит инородно и делает звучание более жестким. > Это то понятно, да и полупроводники изначально нелинейны. Но сейчас их научились > прилично костылить. И прокостылить нежелательные эффекты в чипе имхо проще чем > в огроменной фигне, где все паразитные параметры многократно выше. Тут начинаются > отмазки про "другие" искажения. Мне с инженерной точки зрения это не > нравится. С инженерной точки зрения все наоборот - ламповый усилитель очень простой с минимумом деталей и при этом отлично звучит. Транзисторный требует кучу костылей в виде ООС и других подпорок, дабы удержать его в режиме и заставить сносно звучать. Основный проблемы лампы - размер, вес, потребление, требует начального разогрева. >> Именно такой спектр выдают ламповые усилители. > ИМХО, предпочтителен оригинальный сигнал. А если его звучание кому-то не нравится - > это уже к сигналу вопросы, имхо. Я полностью согласен, поэтому и ушел от ламповой схемотехники, когда появилось возможность строить усилители лучше, чем на лампах. >> 100-500кГц очень хорошо расползаются по всему аудиотракту > Зато давится мелкими L и С. А 50Гц L и C можно > зашибить. Не все так просто. 1. Проникновение 50-100-150 Гц не так критично, нежели попадание в СЧ диапазон. 2. 50 Гц - синус. ИИП - прямоугольник. Для синуса достаточно задавить основной тон и ближайшие гармоники. Для прямоугольника - нужно давить максимально широкий диапазон. Требование к качеству фильтра и его конструкции резко возрастает. Нужно учитывать все мелочи. Для 50 Гц - тупо как можно больше электролитов + немного пленки для подстраховки. 3. У ИИП может возникнуть IMD из-за смены ширины импульса синхронно с потреблением (читай басами). > Если экономить - китайцы экономят на кондерах и обмотках 50Гц > транса. Такой транс на верхушке синусоиды не удерживает сетево (L недостаточно). > Проскакивает сквозной пик тока, dI/dt высокий -> мощная ЭМ волна. AFAIK это возможно только для прямоугольника. Если на индуктивность подавать синус - то часть тока просто выделится на активно сопротивлении в виде тепла. А вот для прямоугольника - да после насыщения будет выброс, что добавляет проблем с проектированием ИИП. > Я бы сказал что они вездесссущи Нет. они остаются в узком диапазоне и наводятся только на относительно длинные проводники. > и устранять их трудно, Как я сказал выше - легче, так как синус 50Гц не критичен к подбору компонентов. > дорого и Не факт. Никто не заставляет покупать black gate. Но если говорить о массовом производстве, где каждый цент на счету - то да, классический трансформаторный БП существенно дороже. > ИМХО задачу следует декомпозировать. Дело железок - передать сигнал "как было". А > (психо)акустикой нехай занимаются музыканты, звукорежи и кто там еще. Не железкино > это дело - приукрасами заниматься. Согласен. >> Почему STM32 содержит эти костыли? Чем плохо с именно с инженерной точки зрения? > STM32 не содержит CGU. Если все блоки тактируются от одного кварца - содержит, просто называется иначе. > А костыли - потому что получается какая-то кривая > частота с ошибкой. Всегда есть какая-то погрешность. С инженерной точки зрения нужно учитывать величину погрешности и исходить из допустимости этой погрешности при решении конкретной задачи. Мне вот лично не нравится число PI - шибко оно дробное и фильтры считать неудобно :) >> Не вижу реальных обоснований, кроме того, что вы лично не любите не круглые частоты. > Я не люблю кривые инженерные решения, особенно когда единственным аргументом "за" является > "мы так привыкли". Не "мы привыкли", а "нет реальной необходимости его менять". При смене мы получи плюсом кратную частоту для кварцев, что на данном этапе развития техники непринципиально. Минусом - сломаем совместимость с уже имеющимися записями и потребление на 9% больше. Для меня лично минусы перевешивают плюсы. >> Естественно, но при прочих равных потребление смарта существенно выше. > А это от условий зависит, имхо. В поезде они наверное помрут за > сравнимое время, высадив всю энергию в антенну. Возможно. Но это не совсем типичный случай.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	157. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 30-Ноя-16, 21:01
	> Так CGU это и есть блок тактирующий остальные - называться он может иначе. У allwinner a10 (даташит попался под руку первым) - "блок" сводится к нескольким разномастным PLL. Нормально? >> ARM - "Lego для чипмейкеров" > Правильно, но все кирпичики нужно зацепить вместе. Ну вот я и сказал за пару довольно распостраненных чипов. Где там у них выделенный блок? > Отсюда общая шина и I2S, так как он часто используется для DAC. И похоже что у нокии I2S на 48кГц висит :) > Проще взять готовый кирпич, чем изобретать его заново. Это денег стоит. Внешний DAC = деньги реализатора системы. Лицензирование блока - деньги чипмейкера. А они жадные. > Как это? Убить PA и запустить вывод напрямую hw:0,0 (без dmix и прочего). aplay -L показывает 2 девайса: default (PulseAudio) и null. aplay -l показывает 2 других девайса. Оба I2S, 1й похож на чип аудиокодека, 2й - синезуб. Если pa стопнуть ... aplay сэмплы в I2S сбагривает. Но звука нет. И я даже догадываюсь почему. > Вообще можно глянуть в аудио драйвере А в алсе это посмотреть утилями нельзя? По косвеным признакам - I2S на 48кГц. > P.S. Было бы интересно узнать сколько будет потреблять mp3/wav при прямом выводе. А смысл? Я не собираюсь ЭТО устройство без пульса гонять. > Возможна одна из причин жора смартов - жирный аудио сервер. Там уйма вариантов источников звука, куда выводить, надо микшировать, коммутировать, ресэмплить, есть разные уровни громкости для разных выводов и проч. Earpiece телефона и динамики/уши - разные вещи, etc. Подозреваю что кроме играния в hw:0,0 - надо делать что-то еще, чтобы звук с кодека шел в нужный вывод. Вероятно это делает пульс (плагины?), согласовывая активность с другими системными компонентами по dbus. Парни из ноклы рассказывали что с одной алсой там никак. > Сейчас вроде мода прямо с соц сетей слушать, но что там и как не знаю - асоциальный я тип :) И это тоже. И ютуб. > В железе многие вещи получаются проще и автоматом. Попробуйте поиграть на софтовой гитаре :) Новость про гитару тут была. Баян. Тьфу, гитара с гентой :). FYI, физика струны относительно простая. > Нужен и софт и железо - одно другого не заменит. И тем не менее, софт может взять на себя многие вещи которые делало железо. Да и в железе нынче high-level synthesis в моде. Мир будет software defined, имхо. Ну и я не хочу чтобы мое железо занималось приукрасами картинки, звука или чего там еще. > Мощные полупроводники имеют относительно низкие частоты Смотря что за низкую частоту считать. Так то мощные полевики даже гигагерцы усиливают в БСках ( интегральный вариант - в RF мобил). Правда они из экзотичных материалов и дорогие. И не знаю насколько их линейность парит. > и нуждаются в ООС для расширения частотного диапазона. Смотрите график Gain vs Freq для ОУ. И у BJT похоже. Но по мере улучшения технологий - кривая сдвигается вверх. > производителя 3$ при партии от 100 шт) и быстрый имеет 8-10 kHz. А чего в нем такого на $3? > что является самой большой проблемой для всех ламповых усилителей. Лампы вообще относительно высоковольтные, неудобно для подключения к остальному. Низковольтные схемы еще и безопаснее и менее требовательны к компонентам. > сокращает жизнь лампе, но звучит он в нем еще лучше. Что-то мне кажется что лампа при этом здорово меняет свойства. Самое очевидное - с анода будет термоэлектронная эмиссия и все что касалось обратной проводимости - отвалится. Да и остальное наверное уедет. > С инженерной точки зрения все наоборот - ламповый усилитель очень простой с > минимумом деталей и при этом отлично звучит. С инженерной точки зрения проще всего было бы взять 1 мелкую микросхему. А кстати есть у вас на примете чип-усилок для мелкого динамика, 0.3-0.5W @ 3.3V? Желательно low power при idle, тривиальная схема ("вход-выход-земля-питание"), мелкость чипа, может еще сигнал EN (чтоб внешний power gating не городить). И чтоб недорого и легкодоставаемо? Так бывает? :) (динамик "смартфонный" или "ноутбучный" -> совсем не hi-fi). > Транзисторный требует кучу костылей в виде ООС и других подпорок, Для дискретных элементов это некая проблема. Для микросхем - там места для костылей много, а использование как раз упрощается. > Основный проблемы лампы - размер, вес, потребление, требует начального разогрева. А у них параметры не дрейфуют? Так, вспоминая ламповые телеки дуревшие от уплывания параметров ламп. > строить усилители лучше, чем на лампах. Я как раз и говорил что полупроводники вроде прилично изучили и развили, проблемы осознали, костылить научились. > Не все так просто. > 1. Проникновение 50-100-150 Гц не так критично, нежели попадание в СЧ диапазон. Откуда проникновение? Если ВЧ удавлено LC и экран нормальный. И откуда СЧ? Как максимум могу представить pulse-skip mode контроллера при легкой нагрузке - в hi-fi фича может потенциально стать багом, но величина бага - на уровне остальных пульсаций :) > 2. 50 Гц - синус. Теоретически. Практически там подключены китайские импульсники, если не сварочные аппараты. Обычно преобладает емкостная нагрузка (импульсники же :P), так что "синус" - не синусоидальный. А питальники на 50Гц почти не уделяют внимание фильтрации ВЧ... > ИИП - прямоугольник. Вбить в индуктивность прямоугольный импульс тока? E = L * dI/dt. При открытом полевике E = напряжение выпрямителя. Форму импульса прикинете? Это же и с магнитным полем. > Для синуса достаточно задавить основной тон и ближайшие гармоники. У вас своя электростанция и клиентом там только усилок? oO > Для прямоугольника - нужно давить максимально широкий диапазон. А где вы в импульснике прямоугольник нашли? В гейте полевика, если он дискретный? :) > Требование к качеству фильтра и его конструкции резко возрастает. На таких частотах даже малые L и C дают сильное ослабление, НЧ давится выпрямителем сети и контроллером, ему 50Гц и т.п. ни о чем, он быстрее регулирует. > тупо как можно больше электролитов + немного пленки для подстраховки. Думаете, сцрачи соседних импульсников вас не касаются? Электролиты vs ВЧ бесполезны, btw. > 3. У ИИП может возникнуть IMD из-за смены ширины импульса синхронно с > потреблением (читай басами). Современные контроллеры бывают и с clock spread - FCC дрючит за EMI. В целом же скорость регулирования там очень даже и сильно выше 50Гц -> меньше C для того же уровня пульсаций. >> Проскакивает сквозной пик тока, dI/dt высокий -> мощная ЭМ волна. > AFAIK это возможно только для прямоугольника. dI/dt - "скорость изменения тока в данный момент". Это и есть описание импульса тока, только generic. Для идеального прямоугольника там бесконечность, btw и из этого кое-что следует ;). > Если на индуктивность подавать синус - то часть тока просто выделится > на активно сопротивлении в виде тепла. Если индуктивности хватало на удержание напруги противо-ЭДСом. Но если на меди сэкономить как китайцы, на верхушке синуса транс уйдет в насыщение. Эффективный L упадет до воздушного сердечника, dI/dt резко увелисится. Будет короткая иголка (острый треугольник). > А вот для прямоугольника - да после насыщения будет выброс, У импульсников бывают разные топологии. Вы про которую из? А то в жесткое насыщение транс не очень то рвутся загонять в многих из, да и прямоугольников в индуктивностях не бывает. > что добавляет проблем с проектированием ИИП. Понятное дело что спроектированный под задачу ИИП работает лучше чем произвольно взятый. И? > Нет. они остаются в узком диапазоне и наводятся только на относительно длинные проводники. Это очень упрощенное понимание мира. Я привел пример как вы можете получить "иголки". То что они повторяются 50 раз в секунду не делает их похожими на 50Гц синус. А 50Гц прямоугольник - это таки прямоугольник. С "бесконечным" dI/dt (реально его не бывает, но приблизиться можно). > Как я сказал выше - легче, так как синус 50Гц не критичен к подбору компонентов. А что насчет соседа с дешевым импульсником без фильтров на той же фазе? > массовом производстве, где каждый цент на счету - то да, классический > трансформаторный БП существенно дороже. То что кто-то бесплатно нашел транс с кучей медяки - не значит что он "дешевый". А найти можно и 100 баксов. Иногда. > Если все блоки тактируются от одного кварца - содержит, просто называется иначе. Там нет явного блока. Есть выбор откуда тактировать и есть 1 PLL и таймеры/делители. См. clock tree если интересно. > и исходить из допустимости этой погрешности при решении конкретной задачи. Это так. Но все-таки, у того же кварца если он не совсем левый и это не какие-то запредельные температуры - ошибка в разы ниже. > Мне вот лично не нравится число PI Я бы тоже сказал что оно на любителя. > Не "мы привыкли", а "нет реальной необходимости его менять". Я не призываю резко ресэмплить уже существующие треки. Но оперировать на новых сигналах имхо логичнее в этой сетке частот. > Минусом - сломаем совместимость с уже имеющимися записями и потребление на 9% > больше. Для меня лично минусы перевешивают плюсы. Потребление одного из туевой хучи блоков. Что в большинстве систем будет разницей на доли процента. Ну и "уже имеющиеся записи" не являются мировой константой. Как эти наделали - так и других наделают. >> сравнимое время, высадив всю энергию в антенну. > Возможно. Но это не совсем типичный случай. Ну как, это стандартный облом тех кто путешествует эпизодичкски. "Как это, он же вчера заряжен был?!"
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	158. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 01-Дек-16, 03:56
	>> Так CGU это и есть блок тактирующий остальные - называться он может иначе. > У allwinner a10 (даташит попался под руку первым) - "блок" сводится к > нескольким разномастным PLL. Нормально? К сожалению сходу не нашел полного datashet'а, лишь краткий с общим описанием блоков. Но даже в нем диаграмма CGU (Clock Generation from PLL +  Bus Clock Generation) занимает три страницы. Настройка очень гибкая - можно получить практически любую частоту. Для аудио выделили вообще отдельный PLL2:  22.5792 / 24.576 = 0.91875, что очень напоминает 44100/48000 = 0.91875. >>> ARM - "Lego для чипмейкеров" >> Правильно, но все кирпичики нужно зацепить вместе. > Ну вот я и сказал за пару довольно распостраненных чипов. Где там > у них выделенный блок? Для a10 - Clock Tree Diagram на трех листах (было бы интересно на даташит от этого блока посмотреть с описанием регистров - там наверное 30-50 страниц будет). Для stm32: http://i.stack.imgur.com/CNhiO.png http://blog.mark-stevens.co.uk/wp-content/uploads/2013/03/ST... > И похоже что у нокии I2S на 48кГц висит :) Возможно. Тут все зависит как в софте настроили. Если интересно, вот набор тесовых файлов на качество ресемплинга: http://knk.square7.ch/resampling Если ресемплинга нет или он хорошо сделан - будут просто звуки тонального набора. При плохом ресемплинге - завоет сирена. Чем громче воет - тем хуже ресемплинг :) >> Проще взять готовый кирпич, чем изобретать его заново. > Это денег стоит. Внешний DAC = деньги реализатора системы. Лицензирование блока - > деньги чипмейкера. А они жадные. Ну разработка собственного блока тоже денег стоит. Тут уж кому что лучше. >> Как это? Убить PA и запустить вывод напрямую hw:0,0 (без dmix и прочего). > aplay -l показывает 2 других девайса. Оба I2S, 1й похож на чип > аудиокодека, 2й - синезуб. Можете вывод показать? > Если pa стопнуть ... aplay сэмплы в I2S сбагривает. Через aplay -D hw:0,0 ? > Но звука нет. > И я даже догадываюсь почему. В alsamixer все правильно? >> Вообще можно глянуть в аудио драйвере > А в алсе это посмотреть утилями нельзя? По косвеным признакам - I2S > на 48кГц. AFAIK - нет. API alsa построено так, что можно спросить - поддерживается ли конкретная частота или попросить найти ближайшую к запрашиваемой, но нельзя получить весь список. Там логика выдачи частот/форматов может быть не совсем однозначной/тривиальной. Например на моей emu1212m два кварца. Я могу переключать их через alsamixer (или вообще тактировать плату от внешнего источника). Соответственно alsa api выдает только ту частоту, которую я выбрал в alsamixer. >> P.S. Было бы интересно узнать сколько будет потреблять mp3/wav при прямом выводе. > А смысл? Я не собираюсь ЭТО устройство без пульса гонять. Дабы понять стоимость PA для данного устройства. > Подозреваю что кроме играния в hw:0,0 - надо делать что-то еще, чтобы > звук с кодека шел в нужный вывод. Вероятно это делает пульс > (плагины?), согласовывая активность с другими системными компонентами по dbus. Крайне мало вероятно. PA это надстройка над alsa. Единственное что приходит в голову - это неверные настройки alsamixer. Возможно PA при остановке их сбрасывает. > Парни из > ноклы рассказывали что с одной алсой там никак. Скорее всего имелся ввиду bluetooth, в котором выкинули прямую работу с alsa. >> В железе многие вещи получаются проще и автоматом. Попробуйте поиграть на софтовой гитаре :) > Новость про гитару тут была. Баян. Тьфу, гитара с гентой :). FYI, > физика струны относительно простая. Дело не в физике, а в контроле и возможностях. Замена обычной клавиатуры на сенсорную - уже вызывает существенный дискомфорт. Что говорить о гитаре, где тысячи нюансов для извлечения необходимого звука. Даже с midi клавиатурами все не просто. Хорошие с рояльной механикой стоят не дешево. Заменить ее софтверной-экранной не реально, разве что побаловаться первые пол часа. >> Нужен и софт и железо - одно другого не заменит. > И тем не менее, софт может взять на себя многие вещи которые > делало железо. Да и в железе нынче high-level synthesis в моде. > Мир будет software defined, имхо. Да, особенно после того, как появилась возможность использовать FIR в realtime. Но даже имея неплохую аудио аппаратуру и опыт ее настройки постарения, я и близко не могу приблизится к звучанию хорошего рояля в зале филармонии. > Ну и я не хочу чтобы мое железо занималось приукрасами картинки, звука > или чего там еще. Согласен. Но учитывая, что многие производители предлагают эквалайзер в виде пресетов pop/rock/jazz/etc + всякие улучшайзеры - большинство считает иначе. > И у BJT похоже. Но по мере улучшения технологий - кривая сдвигается > вверх. >> производителя 3$ при партии от 100 шт) и быстрый имеет 8-10 kHz. > А чего в нем такого на $3? Не знаю (если интересно, то это AD826), просто быстрый и с хорошим выходным током и низкими искажениями. Но звучит он действительно отлично, точнее никак не звучит - совершенно не окрашивает звук. Лет семь-восемь назад я их вообще по 10-12$ покупал в розницу. Возможно сейчас дешевле. >> С инженерной точки зрения все наоборот - ламповый усилитель очень простой с >> минимумом деталей и при этом отлично звучит. > С инженерной точки зрения проще всего было бы взять 1 мелкую микросхему. Это да, но пока не реально. Да и в случае микросхем - мы просто прячем сложность и всецело доверяем производителю, что он не напортачил. > А кстати есть у вас на примете чип-усилок для мелкого динамика, > 0.3-0.5W @ 3.3V? Желательно low power при idle, тривиальная схема ("вход-выход-земля-питание"), > мелкость чипа, может еще сигнал EN (чтоб внешний power gating не > городить). И чтоб недорого и легкодоставаемо? Так бывает? :) (динамик "смартфонный" > или "ноутбучный" -> совсем не hi-fi). Возможно и существует что-то подобное, но я не знаю. Можно взять низковольтный ОУ, но к нему нужна внешняя обвеска, тем более для одно полярного питания. Есть тема (http://player.ru/showthread.php?t=132796) где в мелкий плеер умудрились усилитель на max97220 впихнуть. Возможно стоит поискать что-то подобное. EDIT: Вам везет! Мне только что пришел очередной спам от ali, но на этот раз с пользой: https://www.aliexpress.com/item/1PCS-2-5-5V-2X3W-Mini-Audio-... >> Транзисторный требует кучу костылей в виде ООС и других подпорок, > Для дискретных элементов это некая проблема. Для микросхем - там места для > костылей много, а использование как раз упрощается. Да, но эти костыли иногда боком выходят. Например в виде жесткого и не приятного звука. >> Основный проблемы лампы - размер, вес, потребление, требует начального разогрева. > А у них параметры не дрейфуют? Дрейфуют и нужно ждать 3-5 минут, пока усилитель выйдет на режим. Но для аудио точность режима не особа критична. > Так, вспоминая ламповые телеки дуревшие от > уплывания параметров ламп. Там как минимум тайминги для развертки нужны и схема совсем не тривиальная. > Я как раз и говорил что полупроводники вроде прилично изучили и развили, > проблемы осознали, костылить научились. Да, но в продаже действительно качественные усилители попадаются редко и цены на них не малые. Мне одни компоненты для хорошего усилителя (на микросхемах) обошлись более 100$ для 4W мощности. Это решение лишь для высокоомной и высокочувствительной акустики. Возможно, что сейчас ситуация несколько лучше, но не думаю, что принципиально. >> ИИП - прямоугольник. > Вбить в индуктивность прямоугольный импульс тока? E = L * dI/dt. При > открытом полевике E = напряжение выпрямителя. Форму импульса прикинете? Это же > и с магнитным полем. Да, но спектр будет в любом случае больше, чем от 50гц. Да и как вы верно подметили - будет гадить в сеть, а через сеть наводится на сигнальные кабели.   >> Для синуса достаточно задавить основной тон и ближайшие гармоники. > У вас своя электростанция и клиентом там только усилок? oO Если говорить об аудиофилах - то минимуму серьезный фильтр. Многие вообще ставят ac-dc dc-ac преобразователь с жестко нормировочным thd. >> Для прямоугольника - нужно давить максимально широкий диапазон. > А где вы в импульснике прямоугольник нашли? В гейте полевика, если он > дискретный? :) Коммутация индуктивности не создает помех? >> Требование к качеству фильтра и его конструкции резко возрастает. > На таких частотах даже малые L и C дают сильное ослабление, Так в том и дело, что ИИП создает помехи в плоть до мегагерцев и неучтенная емкость в L или индуктивность в C, могут выйти боком. >> тупо как можно больше электролитов + немного пленки для подстраховки. > Думаете, сцрачи соседних импульсников вас не касаются? Вот поэтом аудиофилы фильтруют все от соседей на входе, а у себя выкидываю ИИП. > Электролиты vs ВЧ бесполезны, btw. "+ немного пленки для подстраховки". > Если индуктивности хватало на удержание напруги противо-ЭДСом. Но если на меди сэкономить Опечалились? Наверное хотели сказать на железе. > как китайцы, на верхушке синуса транс уйдет в насыщение. Эффективный L > упадет до воздушного сердечника, dI/dt резко увелисится. Будет короткая иголка (острый > треугольник). Что-то не вижу. http://www.eltranstech.ru/im/oscil1.jpg http://www.eltranstech.ru/products/primenenie-transformatoro.../ Есть осциллограммы? >> А вот для прямоугольника - да после насыщения будет выброс, > У импульсников бывают разные топологии. Вы про которую из? А то в > жесткое насыщение транс не очень то рвутся загонять в многих из, Естественно в нормальном блоке не должно быть насыщения, я лишь говорю об ошибках проектирования. > да и прямоугольников в индуктивностях не бывает. Если загнать в насыщение - то можно получить нарастание напряжения большее, чем было на входе индуктивности. Так работают магнитные ключи. Это эффект используют в сварочных осцилляторах: http://www.electrik.org/forum/index.php?showtopic=52401 Там чем больше du/dt, тем лучше. >> что добавляет проблем с проектированием ИИП. > Понятное дело что спроектированный под задачу ИИП работает лучше чем произвольно взятый. > И? Проектирование трансформаторного БП на порядок проще - соответственно меньше вариантов накосячить. >> массовом производстве, где каждый цент на счету - то да, классический >> трансформаторный БП существенно дороже. > То что кто-то бесплатно нашел транс с кучей медяки - не значит > что он "дешевый". Так я и сказал - классический трансформаторный БП существенно дороже. Другое дело, что если делать самому - то проще (но дороже) взять трансформаторный БП. >> и исходить из допустимости этой погрешности при решении конкретной задачи. > Это так. Но все-таки, у того же кварца если он не совсем > левый и это не какие-то запредельные температуры - ошибка в разы > ниже. Так для dac 12бит и так выше крыше. На нормальном SoC погрешность будет существенно ниже. >> Мне вот лично не нравится число PI > Я бы тоже сказал что оно на любителя. :) >> Минусом - сломаем совместимость с уже имеющимися записями и потребление на 9% >> больше. Для меня лично минусы перевешивают плюсы. > Потребление одного из туевой хучи блоков. Для плееров это критично - не потерять час-два уже не плохо. Если мы хотим легкую и долго работающую автономно технику - не стоит просто так раскидываться.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	159. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 02-Дек-16, 16:39
	> очень напоминает 44100/48000 = 0.91875. Именно. Он вообще достаточно продвинут. Но если посмотреть clock tree - PLL меньше чем железок. Железки будут шарить PLL -> репрограмить PLL под формат может не катить. Да и насколько кто-то хочет трогать PLL из аудиодрайвера - отдельный вопрос. > на даташит от этого блока посмотреть с описанием регистров Вот: http://dl.linux-sunxi.org/A10/A10 User Manual - v1.20 (2012-04-09, DECRYPTED).pdf >  - там наверное 30-50 страниц будет). Увы, это китайцы, поэтому там лаконично, порой слишком :P. Если вы серьезно про GPS-навигатор, см. https://linux-sunxi.org - может что-нибудь понравится? Там много. > Для stm32: Ну да, вот так. И именно clock generation unit - это там что? Кучка делителей и 1 pll? > Возможно. Тут все зависит как в софте настроили. Похоже что загнали на 48кГц, а остальное - пульс. > Если интересно, вот набор тесовых файлов на качество ресемплинга Спасибо, любопытно - погоняю :) > Ну разработка собственного блока тоже денег стоит. Тут уж кому что лучше. PLL - наверное и бесплатно можно скопипастить. > Можете вывод показать? # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: RX51 [RX51], device 0: AIC34 tlv320aic3x-I2S-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 card 0: RX51 [RX51], device 1: Bluetooth Bluetooth codec-I2S-1 []   Subdevices: 1/1   Subdevice #0: subdevice #0 # aplay -L null     Discard all samples (playback) or generate zero samples (capture) default     PulseAudio (default) > Через aplay -D hw:0,0 ? Да. Ну или hw:0,1 - блутус, он только на 8000Hz согласен. > В alsamixer все правильно? Эм...без пульса не работает: # alsamixer socket(): Address family not supported by protocol ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused alsamixer: function snd_ctl_open failed for default: Connection refused Если пульс вернуть - играет. И alsamixer работает. > AFAIK - нет. API alsa построено так, что можно спросить - поддерживается > ли конкретная частота или попросить найти ближайшую к запрашиваемой, Да я заметил по aplay, погоняв на десктопе, он пишет что хотел и что получил. Но на n900 пульс - золотая рыбка выполнит любое желание :) > но нельзя получить весь список. Там логика выдачи частот/форматов может быть не совсем > однозначной/тривиальной. Вообще, когда я смотрел - апи алсы какое-то странное и не сказать что дружественное. > api выдает только ту частоту, которую я выбрал в alsamixer. Подозреваю что с pll а-ля allwinner тоже нечто такое актуально. > Дабы понять стоимость PA для данного устройства. Устройство без пульса неюзабельно. Там усилок кто-то power gate'ит еще вроде. > Крайне мало вероятно. PA это надстройка над alsa. Размечтались. Это Продукт от Инженеров. Там нормальная интеграция, модульный UI и коммуникации через dbus во все поля. > Единственное что приходит в голову - это неверные настройки alsamixer. > Возможно PA при остановке их сбрасывает. Он там имхо много чего делает. Это серьезный rethink как может выглядеть и работать Linux. Как делать UI c отличным UX и заменяемыми/кастомизабельными компонентами. При том оставаясь дебианом с gtk+2, qt и иксами как core технологии. > Скорее всего имелся ввиду bluetooth, в котором выкинули прямую работу с alsa. А вот звонок. Рингтон орет в динамики. Ответ. Надо переключить в earpiece. А вот юзер хочет громкую связь. Опять динамики. А вот FM. Его уши интересуют. Еще и как антенна. А можно на динамики звук дать. Они все перекидываются по dbus, координируя системную активность. Пульс тоже участвует в этом - он переключает выводы и заведует громкостью. Потому что громкость earpiece и динамиков, плеера и телефона, наушников и блупупа .. - РАЗНЫЕ вещи. Где вы будете с алсой при ЭТОМ? > Дело не в физике, а в контроле и возможностях. Ничему не противоречит переосмыслить UI и парадигмы. Может быть оффлайн синтез и обработка, где реалтайм не жмет и ошибки можно исправить. Можно экспериментировать с другим UI/MMI. Ниоткуда не следует что это идеал, так что все остальное обязано быть хуже. > Да, особенно после того, как появилась возможность использовать FIR в realtime. Я более широко. Эти паттерны столь удачны и впереди того что было до них, что мы увидим много необычных вещей. Ну вот uber - как бы софтварная компания. И как бы новый формат такси. А с автопилотом, нормальной линейной сигнализацией и диспетчеризацией получится next gen транспорта. Когда попасть из A в B - просто, быстро и дешево и - с пунктуальностью швейцарских часов. Без выходных и перерывов на обед, 24/7. > и близко не могу приблизится к звучанию хорошего рояля в зале филармонии. К UI/UX N900 и их системной интеграции тоже не так просто приблизиться в своих системах ;) > пресетов pop/rock/jazz/etc + всякие улучшайзеры - большинство считает иначе. Большинство не знает слово "эквалайзер", имхо :) > Но звучит он действительно отлично, точнее никак не звучит - совершенно не окрашивает звук. Знакомое ощущение. > Это да, но пока не реально. Да и в случае микросхем - мы просто прячем > сложность и всецело доверяем производителю, что он не напортачил. Что до сложности - вы и 1 транзистор задолбаетесь производить сами, да и просто характеризовать каждую деталь. > Мне только что пришел очередной спам от ali, но на этот раз с пользой: Цена прикольная, но я забыл: размер важен. Чужая печатка - это упс. Хотя глядя на их фото, "pam8" по каталогам отвечает на вопрос, спасибо :). > Например в виде жесткого и не приятного звука. Зависит от того чей это дефект - трека или железки. Мне пришлось стереть половину мп3 после покупки более-менее нормальных ушей с плоской ачх и emu10k. > Дрейфуют и нужно ждать 3-5 минут, пока усилитель выйдет на режим. Понятно, не быть им операционным усилителем :) > них не малые. Мне одни компоненты для хорошего усилителя (на микросхемах) > обошлись более 100$ для 4W мощности. Что-то такое можно сказать даже про те же SMPS. Хорошие питальники не дешевые. А если дешево, в лучшем случае это нечто средненькое. В массовом тираже есть соблазн экономии на компонентах. > Да, но спектр будет в любом случае больше, чем от 50гц. Основная часть будет на частоте преобразования. Удавится L и C на выходе. > Да и как вы верно подметили - будет гадить в сеть, ...если экономить на входном фильтре, как китайцы. А в качественных БП с этим ок. > через сеть наводится на сигнальные кабели. Длинных слаботочных аналоговых кабелей я бы избегал. Силовую проводку все-таки никуда не деть. > Если говорить об аудиофилах - то минимуму серьезный фильтр. Многие вообще ставят > ac-dc dc-ac преобразователь с жестко нормировочным thd. А если не заниматься торсионщиной - хватило бы имхо неплохого импульсника с экранированием и фильтрами. Неплохо развяжет все от сети - работает он так. >> А где вы в импульснике прямоугольник нашли? В гейте полевика, если он дискретный? :) > Коммутация индуктивности не создает помех? Помехи имхо в основном дает меняющееся магнитное поле индуктивности. Оно не идеально упрятано в сердечник - все вокруг становится вторичкой (антенной). Остальные поля по сравнению с этим - ерунда. Если кормить индуктвность прямоугольным напряжением, ток в ней будет треугольным. И все это на частоте преобразования. > Так в том и дело, что ИИП создает помехи в плоть до мегагерцев Если L+C давят 100кГц, 1МГц они придушат даже сильнее (хотя паразитные параметры не отменяли). > и неучтенная емкость в L или индуктивность в C, могут выйти боком. Могут, но если вы фильтруете >=100кГц вы их всяко учитываете. > Вот поэтом аудиофилы фильтруют все от соседей на входе, а у себя выкидываю ИИП. А можно было гонять сигналы в цифре и использовать нормальные импульсники. Да и соседей и проводку в хате все-таки не выкинешь. > "+ немного пленки для подстраховки". Я бы не назвал это "подстраховкой" и наверное лучше как раз побольше. Электролиты к тому же даже на звуковой частоте так себе. Индуктивность зверская, ESR большой. По идее это даст некий уход характеристик? > Опечалились? Наверное хотели сказать на железе. На железе реже экономят - оно дешевле. А меди в большую первичку не домотать - милое дело. L падает, сильно. Первичка хуже сопротивляется вталкиванию тока. Тока больше, омического нагрева тоже. В сердечнике максимальное поле сильнее. Если сердечник начнет уходить в насыщение - на верхушке синусоиды в первичку ввалится всплеск тока, т.к. напряжение максимальное, а индуктивность наоборот обвалилась. Всплеск крутой - разлетается хорошо. > Что-то не вижу. http://www.eltranstech.ru/im/oscil1.jpg > http://www.eltranstech.ru/products/primenenie-transformatoro.../ Упомянутый эффект - для тока _первички_ на _переменном_ токе, с _нулевой_ постоянной составляющей. Для простоты "не нагруженный" (малонагруженный) транс. Ваши ссылки - не про это. Постоянное подмагничивание - асимметрирует процесс. А при насыщении - это как воздушный транс, нельзя считать обмотки сильно связанными. Мониторинг вторички покажет не весь процесс - утечкой поля там принебрегать уже нельзя. > Есть осциллограммы? Не помню где видел, в какой-то RTFMнике по трансам, имхо. Формально это ошибка проектирования "недостаточно индуктивности первички". Но может быть и экономией меди. Из того что нашел - эффект достаточно правдоподобно упоминается на http://www.tubeamplifier.narod.ru/mess122.htm Осциллограмма тока при этом будет обычной синусоидой, но в верхней ее части - острая иголка - крутой всплеск когда транс становится "воздушный". Детали зависят от того как сердечник входит в насыщение и насколько много индуктивности не хватило. С сильно недомотанной первичкой транс вообще перегреется и сгорит. > Естественно в нормальном блоке не должно быть насыщения, я лишь говорю об > ошибках проектирования. Есть 2 сильно разных класса. С запасением энергии в сердечнике ("индуктор") и без ("трансформатор"), разные по процессам. Обратноход для аудио наверное не очень: сердечник часто с зазором (для смягчения входа в насыщение), утечки поля больше. И при закрытии FET выбросы сильные т.к. в этот момент вся энергия в магнитном поле и выброс... вбивает энергию во вторичку. Топологии без запасения энергии выглядят интереснее: обычно нет зазора и энергия поля на момент закрытия слита в вторичку. Выбросы при закрытии если и будут то скромнее. > Если загнать в насыщение - то можно получить нарастание напряжения большее, чем > было на входе индуктивности. С насыщением и прочим опять же не так просто. Топологии разные. > Там чем больше du/dt, тем лучше. Низкий du/dt гарантирует нагрев ключа (а где еще напряжению падать?). Пакостит же в основном магнитное поле транса, там логичнее на dI/dt смотреть, имхо. Ну и опять же, рассматривать транс как транс можно только в схемах где он используется как транс. А обратноходы и т.п. - это другое. > Проектирование трансформаторного БП на порядок проще - Я бы не сказал что проектирование сетевого транса - тривиальное занятие. > соответственно меньше вариантов накосячить. "Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили" (следствие закона Мерфи). > Другое дело, что если делать самому - то проще (но дороже) взять трансформаторный БП. Проще оно разве что если удалось найти готовый подходящий транс дешево/бесплатно и устроили габариты и вес того что вышло. > Так для dac 12бит и так выше крыше. На нормальном SoC погрешность будет существенно ниже. В принципе все так, но есть еще I2S. Да и говоря за себя я не вижу смысла оперировать в таких форматах. > Для плееров это критично - не потерять час-два уже не плохо. Если > мы хотим легкую и долго работающую автономно технику - не стоит > просто так раскидываться. У меня плееров нет. На смарте кодек судя по всему нативно в 48кГц работет и в лучшем случае может даже ресэмплинг отвалится - померять потребление с 44100 и 48000 при прочих равных наверное не лишне :)
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	160. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 03-Дек-16, 00:33
	> Но если посмотреть clock tree - PLL > меньше чем железок. Железки будут шарить PLL -> репрограмить PLL под > формат может не катить. Да, но например в clip zip всего два PLL и то второй мы почти никогда не используем, так как последующая система делителей и множителей достаточно гибкая + можно использовать кварц без PLL и просто делить его. > Да и насколько кто-то хочет трогать PLL > из аудиодрайвера - отдельный вопрос. Ну если он специально выделен под аудио - то не использовать его просто не рационально. >>  - там наверное 30-50 страниц будет). > Увы, это китайцы, поэтому там лаконично, порой слишком :P. Ну 38 страниц про настройку тактирования тоже не мало :) Действительно впечатляющие возможности. > Если вы серьезно > про GPS-навигатор, см. https://linux-sunxi.org - может что-нибудь понравится? Там много. Спасибо, гляну. >> Для stm32: > Ну да, вот так. И именно clock generation unit - это там > что? Кучка делителей и 1 pll? Весь clock tree - встроены генераторы, PLL, коммутаторы и делители. >> Возможно. Тут все зависит как в софте настроили. > Похоже что загнали на 48кГц, а остальное - пульс. Тогда печально. >> Можете вывод показать? > Эм...без пульса не работает: > > # alsamixer > socket(): Address family not supported by protocol > ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused > alsamixer: function snd_ctl_open failed for default: Connection refused > > Если пульс вернуть - играет. И alsamixer работает. Глянул - на n900 конфиг alsa поломали, рецепт как починить: http://wiki.maemo.org/N900_Hardware_Audio_Codec >> AFAIK - нет. API alsa построено так, что можно спросить - поддерживается >> ли конкретная частота или попросить найти ближайшую к запрашиваемой, > Да я заметил по aplay, погоняв на десктопе, он пишет что хотел > и что получил. Но на n900 пульс - золотая рыбка выполнит > любое желание :) ALSA делает тоже самое - если железо чего-то не умеет - вставляет dmix. Поэтому я и сказал, что нужен hw:0 - так как это единственный вариант обойти весь софт и посмотреть что умеет железо/драйвер. > Вообще, когда я смотрел - апи алсы какое-то странное и не сказать > что дружественное. Да, шибко наворочен. Но с другой стороны - позволяет делать с железом все что угодно. Кому нужно по проще - лучше использовать sdl или что другое. >> api выдает только ту частоту, которую я выбрал в alsamixer. > Подозреваю что с pll а-ля allwinner тоже нечто такое актуально. Похоже - да. >> Дабы понять стоимость PA для данного устройства. > Устройство без пульса неюзабельно. Там усилок кто-то power gate'ит еще вроде. ИМХО нет. >> Крайне мало вероятно. PA это надстройка над alsa. > Размечтались. Это Продукт от Инженеров. Там нормальная интеграция, модульный UI и коммуникации > через dbus во все поля. UI и dbus к аудио драйверу имеют весьма далекое отношение. И если драйвер писался с прицелом на интеграцию в mainline ядро - то все должно работать. >> Скорее всего имелся ввиду bluetooth, в котором выкинули прямую работу с alsa. > А вот звонок. Рингтон орет в динамики. Ответ. Надо переключить в earpiece. > А вот юзер хочет громкую связь. Опять динамики. А вот FM. > Его уши интересуют. Еще и как антенна. А можно на динамики > звук дать. Они все перекидываются по dbus, координируя системную активность. Пульс > тоже участвует в этом - он переключает выводы и заведует громкостью. > Потому что громкость earpiece и динамиков, плеера и телефона, наушников и > блупупа .. - РАЗНЫЕ вещи. Где вы будете с алсой при > ЭТОМ? Это вам только так кажется :) А теперь суровая реальность: открываем даташит на TLV320AIC34 - и видим полноценный кодек с фантастическими возможностями. Два стерео ЦАП, четыре выхода с собственными микшерами и эквалайзерами. Два стерео АЦП, пять входов с собственными микшерами и DSP (wind noise, microphone EQ, resonance noise, removal). С собственным блоком тактирования: The TLV320AIC34 supports the following standard audio sampling rates: 8 kHz, 11.025 kHz, 12 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, and 96 kHz. При том он имеет две параллельные части, что позволяет ему работать на двух частотах одновременно! Что позволяет (так говорит datasheet) выводить 44.1k на динамик/наушники и 8k на bt одновременно. Также можно использовать разные частоты для ADC и DAC, и при этом не испытывать никаких трудностей. Просто научная фантастика. Все можно делать бесплатно и на аппаратном уровне - минимальная задержка, минимальное потребление cpu, минимальное потребление ram. И что с этим всем сделали? Правильно - поставили PA :) The audio codec supports a flexible digital filter on both the input and output. This can be used to perform equalization with no CPU load. This function is not used, and pulseaudio is used for this task when speakers are enabled. То есть все крутим на CPU, занимаем RAM и едим батарейку. It can also route the audio directly from the FM receiver to the speakers or the headphones, optionally through this hardware EQ module, also reducing power in this usecase, by entirely eliminating CPU usage. Радио сперва оцифровываем, а потом гоним на выход. И удивляемся, как чего оно так много ест. Это было бы смешно, если бы не было так печально - кто-то разработал хороший кодек с потреблением в несколько mA и отличными возможностями. А кто-то взял засунул PA ... >> Это да, но пока не реально. Да и в случае микросхем - мы просто прячем >> сложность и всецело доверяем производителю, что он не напортачил. > Что до сложности - вы и 1 транзистор задолбаетесь производить сами, да > и просто характеризовать каждую деталь. Я и резистор сам задолбаюсь делать :) Однако, простую деталь проще смоделировать и спрогнозировать поведение во всех ситуациях. >> Например в виде жесткого и не приятного звука. > Зависит от того чей это дефект - трека или железки. Мне пришлось > стереть половину мп3 после покупки более-менее нормальных ушей с плоской ачх > и emu10k. На хорошем железе лучше слышны дефекты записи, но воспринимаются они лучше, чем когда они умножаются на дефекты железа. С другой стороны - на хорошей аппаратуре разрыв между хорошей и плохой записью становиться более очевиден.   >> Дрейфуют и нужно ждать 3-5 минут, пока усилитель выйдет на режим. > Понятно, не быть им операционным усилителем :) Ну смотря для чего эти ОУ :) Вообще раньше и осциллографы строили на лапах. Правда они получше качеством, чем в телеках. Были и отдельные партии для оборонки - с более строгими параметрами и проверкой под вибрацией/резким ускорением, так как их и в самолеты ставили. >> Да, но спектр будет в любом случае больше, чем от 50гц. > Основная часть будет на частоте преобразования. Удавится L и C на выходе. Это в теории, на практике зависит от качества L,C, разводки и экранов. >> Да и как вы верно подметили - будет гадить в сеть, > ...если экономить на входном фильтре, как китайцы. А в качественных БП с > этим ок. Все они гадят, а вот на сколько уже зависит от фильтра и качества заземления. >> через сеть наводится на сигнальные кабели. > Длинных слаботочных аналоговых кабелей я бы избегал. Это не всегда возможно. Да и в случае винили - весь тракт аналоговый (за что его и любят), но более подвержен помехам. > Силовую проводку все-таки никуда не деть. Прокладка подальше от сигнальных, саму силовую - в стальные короба и заземлить. >> Если говорить об аудиофилах - то минимуму серьезный фильтр. Многие вообще ставят >> ac-dc dc-ac преобразователь с жестко нормировочным thd. > А если не заниматься торсионщиной - хватило бы имхо неплохого импульсника с > экранированием и фильтрами. Неплохо развяжет все от сети - работает он > так. Так он и будет при ac-dc dc-ac, только очень навороченный. > Если кормить индуктвность прямоугольным напряжением, > ток в ней будет треугольным. И все это на частоте преобразования. Так треугольник по спектру не сильно лучше прямоугольника. >> Вот поэтом аудиофилы фильтруют все от соседей на входе, а у себя выкидываю ИИП. > А можно было гонять сигналы в цифре и использовать нормальные импульсники. Дешевле один действительно хороший ac-dc dc-ac и вынести его в другую комнату, чем встраивать в каждое устройство действительно хороший импулсник, фильтр и экран. >> "+ немного пленки для подстраховки". > Я бы не назвал это "подстраховкой" и наверное лучше как раз побольше. > Электролиты к тому же даже на звуковой частоте так себе. Индуктивность > зверская, ESR большой. По идее это даст некий уход характеристик? Электролиты дают общую энергетический запас и сносно работают до килогерцев, остальное - пленка. Так что для пленки важна не количество, а качество. Обычно стараются несколько номиналов в  параллель ставить - меньше ESR и ESL и поближе к нагрузке - как для uC керамику ставят. >> Опечалились? Наверное хотели сказать на железе. > На железе реже экономят - оно дешевле. А меди в большую первичку > не домотать - милое дело. L падает, сильно. Да, но тогда получается все наоборот - когда мало меди и много железа - сердечник в принципе нельзя загнать в насыщение. Ведь насыщение возникает от большого магнитного потока. А что бы его создать нужно наоборот много меди и мало железа. > Первичка хуже сопротивляется > вталкиванию тока. Тока больше, омического нагрева тоже. В сердечнике максимальное поле > сильнее. Нет, так как вместо магнитного поля (реактивное сопротивление) мы тратим ток на активном сопротивлении. Магнитное поле падает, а нагрев растет. > Упомянутый эффект - для тока _первички_ на _переменном_ токе, с _нулевой_ постоянной > составляющей. Для простоты "не нагруженный" (малонагруженный) транс. Ваши ссылки - не > про это. Постоянное подмагничивание - асимметрирует процесс. А при насыщении - > это как воздушный транс, нельзя считать обмотки сильно связанными. Мониторинг вторички > покажет не весь процесс - утечкой поля там принебрегать уже нельзя. ОК, понятно. Но как вы сами отметили - экономить на железе нет смысла. Похоже это больше применимо к ИИП, так как там вполне можно ошибиться с выбором феррита или рабочая частота может уплыть. >> Проектирование трансформаторного БП на порядок проще - > Я бы не сказал что проектирование сетевого транса - тривиальное занятие. Там все укладывается в простой калькулятор. Так как работать ему на синусе со строго заданным напряжением и частотой. Да и не целесообразно мотать самому силовые трансформаторы, когда можно купить готовый, любого размера/мощности и под все стандартные выходные напряжения. >> соответственно меньше вариантов накосячить. > "Если вам кажется что дела идут хорошо, значит вы просто чего-то не > заметили" (следствие закона Мерфи). Для классического БП: покупаем трансформатор (в datasheet есть все его данные), ставим диодный мост и конденсаторы. LDO по необходимости. Из приборов нужен только мультиметр. Для ИБП - подбираем контроллер, читаем даташит и изучаем все особенности, рассчитываем/мотаем транс, подбираем полевки, диоды, конденсаторы, дросселя, тщательно продумываем разводку, делаем плату, а затем надеемся, что нигде не ошиблись, ибо широко полосной спектроанализатор для анализа помех на выходе и входе недоступен простому смертному. Самое обидное, что можно накосячить на любом этапе и не заметить :( Так что лично я по-прежнему для критичных вещей (по помехам или безотказности) ставлю обычные трансформаторы. А для остального конечно ставлю ИИП - ибо если помехи не принципиальны, то ИИП вне конкуренции.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	161. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Дек-16, 22:49
	> + можно использовать кварц без PLL и просто делить его. Так у вас девайс посвящен выводу аудио и наверное на одно назначение. Там чего доброго еще и кварц "удобный"? > Ну если он специально выделен под аудио - то не использовать его просто не рационально. Кроме этого есть еще подходы к работе с клоками в ядре и возможность что PLL юзался другой железкой. Но в целом согласен. > Ну 38 страниц про настройку тактирования тоже не мало :) Действительно впечатляющие возможности. Про конкретно этот PLL там как-то лаконично, ряд возможностей вообще указано что они есть. А описания как работает - не вижу. > Весь clock tree - встроены генераторы, PLL, коммутаторы и делители. Если настаиваете - ок, пусть будет чем-то типа аналога CGU. В конце концов, регистры железок сгруппировали. Но в целом это имхо лишь несколько железок. PLL, делители и еще по мелочи. > Тогда печально. Прописал конфиг. Без пульса - звука нет :). Частоты из даташита пашут, проверил 96000, 48000, 44100 и 32000. Врубив пульс а потом aplay -D pcm.real (как в конфиге). Как бы сравнить потребление? Системный плеер юзал пульс. Устроит забег "aplay + wav -> pulse" vs "aplay + wav -> hw"? И для каких частот? 48? 44.1? 96? Smth else? > Глянул - на n900 конфиг alsa поломали, Скорее, предотвратили алсапроблемы НЕПРИЕМЛИМЫЕ в таком девайсе. "Device or resource busy"? В телефоне это неприемлимо. > рецепт как починить: http://wiki.maemo.org/N900_Hardware_Audio_Codec Я это "починил" лишь посмотреть hw/driver caps. > ALSA делает тоже самое - если железо чего-то не умеет - вставляет dmix. В алсе имхо продолбались сделав dmix опцией. Как это должно выглядеть? Кодинг ресэмплера в fallback path проги? Да щаз! > Да, шибко наворочен. Но с другой стороны - позволяет делать с железом все что угодно. Большинство людей хочет просто попасть из точки A в B а не наворачивать мертвые петли. > Кому нужно по проще - лучше использовать sdl или что другое. libsdl для штук типа pidgin - перебор. Они и юзают пульс, особенно в нокии. Кстати вы слышали как libsdl ресэмпл делает? Libsdl 1.x умеет ЖЕСТОКО косячить. Нарывался. > UI и dbus к аудио драйверу имеют весьма далекое отношение. К низкоуровневому драйверу - да. Но по дбасу анонсируется подключение ушей, входящие звонки, меняются уровни громкости и куда выводить, etc. Это - системная интеграция. > И если драйвер писался с прицелом на интеграцию в mainline ядро - то все должно работать. Понятие о "все" в смартфоне обширно. Например, громкости в программе "телефон" и "плеер" - разные. В earpiece один уровень. Плеер в уши - другой. Я не хочу телепать громкость постоянно. Пульс и остальные части системы это обыгрывают по dbus, получается... нормальный UX смарта! > Это вам только так кажется :) Я вижу разные громкости в телефоне и плеере. И вижу что без пульса аудио нет. Там много вариантов вывода и коммутации, пульсом активно рулят по dbus системные компоненты (а могут и сторонние виджеты). > А теперь суровая реальность: открываем даташит на TLV320AIC34 - и видим полноценный > кодек с фантастическими возможностями. Это хорошо. Но смарт состоит не только из железок. Хорошее железо - ничто, если не обеспечит хороший UX. Нокия сделала сбалансированное решение с хорошим UX, имхо. А UX хардварного плеера меня НЕ УСТРАИВАЕТ. > динамик/наушники и 8k на bt одновременно. Также можно использовать разные частоты > для ADC и DAC, и при этом не испытывать никаких трудностей. Вам нравится железка из смартфона? Что-то новое. > минимальная задержка, минимальное потребление cpu, минимальное потребление ram. Но посмотрим на юзкейсы? Это не плеер, приоритеты другие. Аудио не основная статья расходов энергии, а вот гибкость и интеграция с системой - ожидаются. > И что с этим всем сделали? Правильно - поставили PA :) Без него они бы не смогли нормальный UX и интеграцию. Пульс и роутинг аудио через него все это обеспечивают, включая вмняемое поведение аудио, ожидаемое от телефонов и смартов. Так что плеер заткнется или сделает тише при звонке, а слушая FM я не пропущу мсг в IM. > То есть все крутим на CPU, занимаем RAM и едим батарейку. С другой стороны 1) Если звук ходит через софт - его можно записать. 2) Отдельные уровни громкости разных программ - мастхэв. 3) Реакция на события типа втыкания ушей и т.п.. Пульс это умеет. Он даже на лаптопе это по минимуму обрабатывает. 4) Микширование разных потоков. FM аппаратно - круто. А смикшировать, чтобы юзер звонок не пропустил и "бзынь!" из мессенжера - на те же уши? > also reducing power in this usecase, by entirely eliminating CPU usage. Не хотите posix api и ФС себе вынести? Оверхед же. ATA-командами в диск прямо из проги - веселее будет. Спасибо, но мне не требуется UX из эпохи MSDOS. > Радио сперва оцифровываем, а потом гоним на выход. И удивляемся, как чего оно так много ест. Зато можно записать, микшируется с остальными звуками, работает системный регуль громкости и проч. Алсо, более актуальное мне онлайн-радио лопает больше, HSPA модемом или вафлей. FM я редко слушаю - в смарте оно "до кучи". А вы можете купить себе отдельный FM приемник в пару к отдельному плееру, если вам это надо. > А кто-то взял засунул PA ... Потому что в нокии работали нормальные инженеры и управленцы. Они знали что гонку за идеалом иногда надо остановить. Важен общий баланс и UX, а не идеал в второстеменном corner case. > Я и резистор сам задолбаюсь делать :) А я делаю. Специально нихрома купил. Симуляторы нагрузки. Иногда развлеrаюсь с DC-DC и т.п.. На перспективу хочу обкатать технологии в духе http://spritesmods.com/?art=rpi_arcade&page=5 или http://forum.fonarevka.ru/showthread.php?t=26562 - прикольные классы схем, я хочу чуть иное, но идея та же самая. > Однако, простую деталь проще смоделировать и спрогнозировать поведение во всех ситуациях. У "простых" деталей - уйма вторичных/паразитных параметров. И как только токи посильнее или частоты повыше... ну в общем spice симулировал FET-ы довольно приблизительно, когда я смотрел. > На хорошем железе лучше слышны дефекты записи, но воспринимаются они лучше, чем > когда они умножаются на дефекты железа. ИМХО, железу лучше всего передавать сигнал с входа на выход как было, имхо. > разрыв между хорошей и плохойзаписью становиться более очевиден. Я заметил :) > Ну смотря для чего эти ОУ :) ОУ изначально задуманы для прецизионных операций с аналоговыми сигналами, вплоть до вычислений. > Вообще раньше и осциллографы строили на лапах. ... > в самолеты ставили. Я предпочту чтобы пилот оперировал UI как в A320 и новых боингах хотя-бы. > Это в теории, на практике зависит от качества L,C, разводки и экранов. Принцип "как заплачено так и зафигачено" в инженерии везде. > Все они гадят, а вот на сколько уже зависит от фильтра и качества заземления. Через кучу индуктивностей и кондеров и экран не погадишь. Китайцы просто экономят. И на экране, и на фильтрах. Китайская логика проста: и без них работает же. > Это не всегда возможно. Да и в случае винили - весь тракт > аналоговый (за что его и любят), но более подвержен помехам. Сама технология привносит туеву хучу искажений всех мастей, и линейных и не очень. Не вижу рациональный пойнт. > Прокладка подальше от сигнальных, саму силовую - в стальные короба и заземлить. Вариант, но только для тех кто расперся переложить всю электрику или изначально заложил в проект. И если рядом никого/ничего сильноточного нет. > Так он и будет при ac-dc dc-ac, только очень навороченный. Под вторым DC-AC имеется в виду сам усилитель? oO > Так треугольник по спектру не сильно лучше прямоугольника. Спектр там в любом случае гармоники частоты коммутации в основном. Придушить это можно мелкими L и C. > Дешевле один действительно хороший ac-dc dc-ac и вынести его в другую комнату, > чем встраивать в каждое устройство действительно хороший импулсник, фильтр и экран. ИМХО это нездоровое маньячество. Импульсник к тому же можно и не встраивать, как в ноутах. > Электролиты дают общую энергетический запас Проблема этого запаса в неизвлекаемости: нельзя быстро вытащить когда понадобилось. А потом уже поздно. Так то в розетке еще больше энергии, но извлекается не всегда. ESR/ESL создают ПОС по напряжению. При достаточной величине провалов даже будет возбуд, имхо (as seen in LDOs). Керамика тоже разная бывает. У вас вся керамика NP0, невзирая на цену и низкую плотность энергии? Или "какая-нибудь"? У любой керамики != np0 - навалом закидонов. > и сносно работают до килогерцев, остальное - пленка. Так что для пленки > важна не количество, а качество. ИМХО количество должно обеспечивать объем энергии достаточный для формирования импульсов в желаемой виде, пока электролиты тормозят. Иначе напряжение провалится, импульсы будут заниженной амплитуды и не обязательно синус даже. > Обычно стараются несколько номиналов в  параллель ставить - меньше ESR и ESL Снизить ESR и ESL можно и параллелингом одинаковых. Пойнт другой. У разных номиналов разные кривые импеданс vs частота, совместное использование разных - частично компенсирует бажность откликов, предотвращая острые резонансы. > и поближе к нагрузке - как для uC керамику ставят. Так uC из-за CMOSной сущности - импульная штука. Электролиты на временах порядка времени переключения вентиля - ни о чем. Напряжение провалится, схема сглючит. > Да, но тогда получается все наоборот - когда мало меди и много > железа - сердечник в принципе нельзя загнать в насыщение. Вы забыли про индуктивность обмотки. Она резко падает -> растет ток. > Ведь насыщение возникает от большого магнитного потока. А что бы его > создать нужно наоборот много меди и мало железа. IIRC индуктивность обмотки пропорциональна КВАДРАТУ числа витков. Это перевешивает. Если бы индуктивности не было, ток был бы ограничен только омическим сопротивлением обмотки. Что будет с трансом без сердечника (хорошее приближение) - легко проверить ;). Не менее просто цепануть вторичку с малым числом витков в сеть. Там витков круто не хватает, а сердечник тот же. Только транс во что-нить огнеупорное суньте ;). Ток первички "правильного" ненагруженного транса низкий: ЭДС самоиндукции уравновешивает сетевое. Это требование и определяет число витков первички. Активное сопротивление (почти) не работает. А если отмотать - индуктивность упадеь. Ток растет, поток зависит и от тока. В целом поле усилится. У транса увеличится ток ХХ, на верхушках сердечник будет насыщаться, индуктивность - обваливаться. Тут то и ввалится всплеск, ограниченный лишь активным сопротивлением и "воздушной" индуктивностью. Если индуктивности грубо не хватило (как с маловитковой вторичкой) - ток будет ограничен лишь активным сопротивлением. Транс не кипятильник, на рассев P=U^2*R не рассчитан. Сгорит по перегреву первички. По той же причине транс умрет от DC или сильно сниженной частоты. А врубить 50Гц транс на 60Гц - валидно. У него будет "избыток витков", но минусами только цена и габариты. > Нет, так как вместо магнитного поля (реактивное сопротивление) мы тратим ток на > активном сопротивлении. Магнитное поле падает, а нагрев растет. Поле НЕ падает - самоиндукция первички противодействует меньше -> тока втолкнется больше -> усилится поле. Из-за N^2 в этом месте фактор перевесит. Транс с недостаточными витками первички выгорает по перегреву обмотки. А активное сопротивление в трансе вообще паразитный параметр. Транс - индуктивность, а не кипятильник. То что он греется это вообще баг и снижает КПД. > ОК, понятно. Но как вы сами отметили - экономить на железе нет смысла. Зато медь дорогая, у 50Гц трансов обмотки большие. Не могут они маленькие быть. Если провод тонкий - паразитное омическое растет и греет транс при попытках откачивать мощщу. И надо много витков чтобы удерживать сетевое. Большая катушка и так и сяк. > Похоже это больше применимо к ИИП, так как там вполне можно ошибиться > с выбором феррита или рабочая частота может уплыть. Там запас оставить дешево: обмотки мелкие. Высокочастотное напряжение удерживается меньшей индуктивностью. Это позволяет круто скостить число витков. Омическое снижается. Сплошной профит. Повышение частоты сдержвается в основном скоростями полевиков и материалами сердечника. Сердечник от частых перемагничиваний начинает греться, обычные материалы живут до 100-500кГц. Выше можно, но требуются более экзотичные материалы сердечника. Это уже не про экономию. > Там все укладывается в простой калькулятор. Так как работать ему на синусе > со строго заданным напряжением и частотой. И все-таки там довольно много процессов которые надо учесть. Полная физика с нагрузками и паразитными параметрами не сказать что тривиальная. Вот даже вы физику транса не совсем поняли и сделали неправильный вывод. Легко опровергаемый экспериментом с включением мелкой обмотки на том же сердечнике в сеть. Транс сгорит за обозримое время :P. Если менее нагло не домотать - не сгорит, но нагрев при ХХ повысится и могут начаться "прострелы" первички всплесками тока на максимумах. Кст, современные импульсники обычно экономичнее на ХХ. > Да и не целесообразно мотать самому силовые трансформаторы, когда можно > купить готовый, любого размера/мощности и под все стандартные выходные напряжения. И там у производителя соблазн сэкономить на большой первичке. Если это сделают, аудиофил получит сюрприз. Надо угадать с трансом. Лучше всего - тороид (нет вылезаний поля через зазоры сердечника) и с избыточной даже на максимуме (e.g. ~250V) первичкой. Если удалось такие обмотки втиснуть. Про экономию речь уже не идет. И опять же, выбор между долботней (найти хороший транс или самому мотать заведомо с избытком) или дорогим кастомом. А нахаляву или дешево чаще всего сердечник формы E+I - утечки в зазорах. И хз под какие критерии первичка делалась. Небольшие прострелы часто считают "допустимыми". Для экономии меди. > Для классического БП: покупаем трансформатор (в datasheet есть все его данные), ставим > диодный мост и конденсаторы. LDO по необходимости. Из приборов нужен только мультиметр. А потом замечаем что транс не домотали и он дает импульсные помехи, LDO греется как печь. А без этого - он из стабилизации выйдет, т.к. в сети может быть и 180 и 240. ВЧ помехи могут внаглую пролезть. И 50Гц от огромного транса могут навестись, поле приличное. И "сосед со сваркой" импульсником получще фильтруется. > Для ИБП ...формулируем задачу и желаемые свойства. Выбираем топологию, после чего > подбираем контроллер, читаем даташит и изучаем все особенности, рассчитываем/мотаем транс, ... > Самое обидное, что можно накосячить на любом этапе и не заметить :( Однако осцил (и даже мультиметр понимающий ВЧ-переменку) спалят пульсации. А поскольку китайцы хилые инженеры, в даташитах бывают критичные куски разводки, параметры трансов на типовые случаи и т.п.. > Так что лично я по-прежнему для критичных вещей (по помехам или безотказности) > ставлю обычные трансформаторы. Не испытываю проблем с помехами импульсников, а брошенные в воздухе щупы сообщают что 50Гц - доминируют. Классические питальники большие, тяжелые и неэффективные. ХХ прожорливее, LDO топит воздух. Спору нет, телегу можно сделать и чуть ли не одним топором, но что-то желающих это делать осталось немного. > А для остального конечно ставлю ИИП - ибо если помехи не принципиальны, то ИИП вне конкуренции. Да они и помех особо не создают, фирменные комповые питальники например зачастую неплохо сделаны. Капитальный фильтр на входе, дроссели на выходе, корпус железный. Любители emu и проч не очень плюются вроде, хотя там под боком крутой импульсник. Кстати, можно после импульсника LDO поставить. Т.к. он только для ripple rejection - падение напруги на LDO быть малым. Он и ripple срежет и не будет при этом печкой. А что до надежности - посчитать импульсник так что он даже 380 ("перекос фаз") выдержит, хоть без ограничений по времени работы. Транзюки вольт на 700+ бывают (даже в интеграшках для мобилочных зарядок), диоды чаще всего на 1000V, с запасом на приколы и выбросы. Можно сделать условно-вечный агрегат. Можно даже от электролитов (частая точка отказа) избавиться. Вопрос только в жабе - насколько кто готов за улучшение параметров платить. Неубиваемый и вечный питальник - хорошо. Но он будет дороже обычного. А с классикой такие запасы надежности уже напряжны по габаритам/массе и повсеместным запасам параметров, Включая и вторичку.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	162. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 12-Дек-16, 16:29
	> Там чего доброго еще и кварц "удобный"? Нет, стандартный 24 MHz. > Про конкретно этот PLL там как-то лаконично, ряд возможностей вообще указано что > они есть. А описания как работает - не вижу. Я тоже люблю более подробные описания. Возможно для него есть еще appnotes (или должны были быть ;) > Если настаиваете - ок, пусть будет чем-то типа аналога CGU. В конце > концов, регистры железок сгруппировали. Но в целом это имхо лишь несколько > железок. PLL, делители и еще по мелочи. Так а чего еще желать? Есть возможность из одного кварца получить множество не кратных частот и тактировать от них все остальные блоки. > Прописал конфиг. Без пульса - звука нет :). alsamixer крутили (громкости/mute/переключатели)? > Частоты из даташита пашут, > проверил 96000, 48000, 44100 и 32000. Врубив пульс а потом aplay > -D pcm.real (как в конфиге). Как бы сравнить потребление? Системный плеер > юзал пульс. Устроит забег "aplay + wav -> pulse" vs "aplay > + wav -> hw"? И для каких частот? 48? 44.1? 96? > Smth else? Было бы интересно весь ряд (32-96) таким образом прогнать (узнаем зависимость потребления от частоты для данного устройства и сколько стоит pa и его ресемплинг). Но без звука эксперимент может быть не совсем чистым - возможно mute аппаратно отключает выходной усилитель. >> Глянул - на n900 конфиг alsa поломали, > Скорее, предотвратили алсапроблемы НЕПРИЕМЛИМЫЕ в таком девайсе. "Device or resource busy"? > В телефоне это неприемлимо. Пока запущен pa такого не может быть в принципе - так как он сам монопольно занял устройство. >> ALSA делает тоже самое - если железо чего-то не умеет - вставляет dmix. > В алсе имхо продолбались сделав dmix опцией. Как это должно выглядеть? Кодинг > ресэмплера в fallback path проги? Да щаз! Все программа тупо должны отсылать все в устройство "default". Все остальные решения принимает alsa. При том весьма гибко - ресемплинг и dmix вставляется при необходимости (если железо не умеет). К примеру моя emu1212m умеет сама смешивать 32 потока, от dmix для нее будет только вред. Если пользователь указал использование hw, значит ему нужен прямой доступ к железу (для минимальной задержки/минимальной нагрузки/запуска аудиосервера/измерения качества звуковой платы). Если это сделал маинтейнер пакета - это признак профнепригодности. >> Да, шибко наворочен. Но с другой стороны - позволяет делать с железом все что угодно. > Большинство людей хочет просто попасть из точки A в B а не > наворачивать мертвые петли. Зависит от задачи. Если цель - проиграть уведомление - проще вообще вызвать готовый плеер. >> Кому нужно по проще - лучше использовать sdl или что другое. > libsdl для штук типа pidgin - перебор. Pidgin вообще тянет за собой gstreamer, вот уж действительно overkill. > Кстати вы слышали как libsdl ресэмпл делает? Libsdl 1.x > умеет ЖЕСТОКО косячить. Нарывался. Но зачем? Alsa его делает сама (алгоритм/качество - на выбор). > Понятие о "все" в смартфоне обширно. Например, громкости в программе "телефон" и > "плеер" - разные. Это легко решается и в alsa: можно создать отдельные виртуальные устройства (phone, player, game, etc) и выводить каждый класс программ в свое устройство со своей громкостью. Это удобно тем, что регулятор будет един для всего класса (а не каждой программе по регулятору как любит pa). Если же приложению действительно нужен собственный регулятор - то проще его встроить в приложение (как в играх - где их может быть несколько в одном приложении). > В earpiece один уровень. Плеер в уши - > другой. Я не хочу телепать громкость постоянно. У данного кодека это реализовано на аппаратном уровне. > Пульс и остальные части > системы это обыгрывают по dbus, получается... нормальный UX смарта! Это можно сделать и без dbus и pa - освободить память/cpu и увеличить время автономной работы. > Там много вариантов вывода и коммутации, пульсом активно > рулят по dbus системные компоненты (а могут и сторонние виджеты). А можно рулить через amixer/alsa api. И о чудо - без dbus :) > Это хорошо. Но смарт состоит не только из железок. Хорошее железо - > ничто, если не обеспечит хороший UX. Нокия сделала сбалансированное решение с > хорошим UX, имхо. А UX хардварного плеера меня НЕ УСТРАИВАЕТ. На этом кодаке аппаратно можно делать почти все. ИМХО в данном случае Nokia урезала возможности, а не расширила. Вы можете на N900 используя PA на динамик вывести звуки от игрушки и параллельно музыку в наушники (в наушниках только музыка, в динамике только звуки игрушки)?  Аппаратно такое доступно. Более того: у игры может быть 48 kHz, а у музыки 44.1, но ресемплинга не будет нигде. > Вам нравится железка из смартфона? Что-то новое. Как кодек для смарта - да, я даже не подозревал что подобное (2 параллельных блока с большой функциональностью) существует. Для остальных применений - overkill, да и качество звука среднее. >> И что с этим всем сделали? Правильно - поставили PA :) > Без него они бы не смогли нормальный UX и интеграцию. Не вижу технической проблемы. > Пульс и роутинг аудио через него все это обеспечивают, Реализовано аппаратно. > включая вмняемое поведение аудио, > ожидаемое от телефонов и смартов. Так что плеер заткнется или сделает > тише при звонке, а слушая FM я не пропущу мсг в > IM. Используя alsa + аппаратные возможности кодека можно сделать и более сложные вещи. >> То есть все крутим на CPU, занимаем RAM и едим батарейку. > С другой стороны > 1) Если звук ходит через софт - его можно записать. Ничто не мешает включить adc при необходимости. А так получаем кроме жора батарейки еще и потери в качестве звука, так как прогоняем его через adc > pa > dac. Для fm не критично, но ...   > 2) Отдельные уровни громкости разных программ - мастхэв. Можно сделать и в alsa. > 3) Реакция на события типа втыкания ушей и т.п.. Пульс это умеет. Можно сделать и в alsa. > 4) Микширование разных потоков. FM аппаратно - круто. А смикшировать, чтобы юзер > звонок не пропустил и "бзынь!" из мессенжера - на те же > уши? Реализовано аппаратно. > Не хотите posix api и ФС себе вынести? Оверхед же. ATA-командами в > диск прямо из проги - веселее будет. Спасибо, но мне не > требуется UX из эпохи MSDOS. Некорректное сравнение. Тут больше подойдет другая аналогия: имеем две навороченные видеоплаты, но вместо использования их аппаратного ускорения, тупо все считаем на cpu и выводим все только через одну плату. >> Радио сперва оцифровываем, а потом гоним на выход. И удивляемся, как чего оно так много ест. >> А кто-то взял засунул PA ... > Потому что в нокии работали нормальные инженеры Я лично знаю человека, работавшего над n7xx (первый планшет) и возможно более поздними. Да - инженеры толковые. > и управленцы. А вот с этими все не однозначно. > Они знали что гонку за идеалом иногда надо остановить. > Важен общий баланс и UX, > а не идеал в второстеменном corner case. Да UX уделялось больше времени, чем оптимизации. Но это не значит, что dbus и pa незаменимы и идеально подходят для данной задачи. Скорее это компромисс, позволяющий быстрее выпустить продукт, пусть и в ущерб потреблению ram/cpu/акб. Да и качеству звука: ведь программное микширование не бесплатно - нужно уменьшить звук на несколько бит, дабы при сложении всех источников не получить клиппинг. В итоге при прослушивании музыки мы получим 14 бит вместо 16 :( >> Я и резистор сам задолбаюсь делать :) > А я делаю. Специально нихрома купил. А на 100k? Да еще smd? :) >> Однако, простую деталь проще смоделировать и спрогнозировать поведение во всех ситуациях. > У "простых" деталей - уйма вторичных/паразитных параметров. И как только токи посильнее > или частоты повыше... ну в общем spice симулировал FET-ы довольно приблизительно, > когда я смотрел. Верно, а в сложной тысячи деталей и у каждой свои вторичные параметры. Это как с софтом - чем больше программа, тем больше в ней багов. Они в основном мелкие, но иногда очень досадные. >> Ну смотря для чего эти ОУ :) > ОУ изначально задуманы для прецизионных операций с аналоговыми сигналами, вплоть до вычислений. Возможно, но сейчас круг их применения очень широк - отсюда и большой ассортимент.   >> Все они гадят, а вот на сколько уже зависит от фильтра и качества заземления. > Через кучу индуктивностей и кондеров и экран не погадишь. Любой фильтр имеет свои конечные параметры. Вряд ли обычным фильтром (разумных размеров и цены) можно задавить больше 10-30 dB. Как говорится - чисто не там где убирают, а там где не мусорят. > Сама технология привносит туеву хучу искажений всех мастей, и линейных и не > очень. Не вижу рациональный пойнт. Считается, что разрешение у аналогового тракта больше. Но на практике - сомневаюсь. Да и пишут сейчас все все равно на цифру. Так что - да, практического смысла мало. Разве что человек просто доставляет удовольствие возится с винилом. >> Так он и будет при ac-dc dc-ac, только очень навороченный. > Под вторым DC-AC имеется в виду сам усилитель? oO Нет, это часть самого преобразователя. Типа как On-line ИБП, но с более строгими выходными параметрами. > ИМХО это нездоровое маньячество. Зависит от задачи. В измерительных лабораториях наверное и не такое бывает. Слышал, что на ADC с >120 dB разрешением и открытие форточки влияет :) > Импульсник к тому же можно и не встраивать, > как в ноутах. Как вариант. Но лучше тогда вынести обычный трансформаторный БП и питать всю аппаратуру постоянным током. >> Электролиты дают общую энергетический запас > Проблема этого запаса в неизвлекаемости: нельзя быстро вытащить когда понадобилось. А потом > уже поздно. Так я и говорю - работают прилично работают до килогерцев. В ИИП с этим хуже - там электролиты на входе и частоты большие. Да и сами электролиты не любят быстрого разряда/заряда. > При достаточной величине провалов > даже будет возбуд, имхо (as seen in LDOs). Керамика тоже разная > бывает. У вас вся керамика NP0, невзирая на цену и низкую > плотность энергии? Для себя - да. Да и много керамики не нужно, так как есть еще и пленка. > ИМХО количество должно обеспечивать объем энергии достаточный для формирования импульсов > в желаемой виде, пока электролиты тормозят. Иначе напряжение провалится, импульсы будут > заниженной амплитуды и не обязательно синус даже. Для аудио это не проблема - там достаточно небольшого количества пленки, а электролитов столько, что усилитель играет еще некоторое время, после отключения питания. >> Обычно стараются несколько номиналов в  параллель ставить - меньше ESR и ESL > Снизить ESR и ESL можно и параллелингом одинаковых. Пойнт другой. У разных > номиналов разные кривые импеданс vs частота, совместное использование разных - частично > компенсирует бажность откликов, предотвращая острые резонансы. Естественно нужно уменьшить ESR и ESL в максимально широком диапазоне. > А если отмотать - индуктивность упадеь. Ток растет, поток > зависит и от тока. В целом поле усилится. У транса увеличится > ток ХХ, на верхушках сердечник будет насыщаться, индуктивность - обваливаться. Тут > то и ввалится всплеск, ограниченный лишь активным сопротивлением и "воздушной" индуктивностью. Все, дошло :) Но тут другой момент - какой смысл мотать трансформатор толстым проводом и малым количеством витков? Проще намотать больше витков тонким проводом. По меди выйдет тоже, но не будет насыщения. > Не могут они маленькие > быть. Если провод тонкий - паразитное омическое растет и греет транс > при попытках откачивать мощщу. Так трансформатор подбирается исходя из нагрузки. > И надо много витков чтобы удерживать сетевое. > Большая катушка и так и сяк. Пропорционально мощности. В одном проекте я использовал на подобии этих: https://www.elpro.org/gb/2760-print-transformers-19va >> Похоже это больше применимо к ИИП, так как там вполне можно ошибиться >> с выбором феррита или рабочая частота может уплыть. > Там запас оставить дешево: обмотки мелкие. Высокочастотное напряжение удерживается меньшей > индуктивностью. Это позволяет круто скостить число витков. Да но тут есть соблазн экономить на феррите. >> Там все укладывается в простой калькулятор. Так как работать ему на синусе >> со строго заданным напряжением и частотой. > И все-таки там довольно много процессов которые надо учесть. Полная физика с > нагрузками и паразитными параметрами не сказать что тривиальная. Вот даже вы > физику транса не совсем поняли и сделали неправильный вывод. Ибо я трансформаторы не мотаю, а использую готовые :) > Если менее нагло не домотать > - не сгорит, но нагрев при ХХ повысится и могут начаться > "прострелы" первички всплесками тока на максимумах. Тем не менее, я так и не нашел в гугле таких осциллограмм. Да и в любом случае такие трансформаторы легко определить по току ХХ и нагреву. > И там у производителя соблазн сэкономить на большой первичке. Если это сделают, > аудиофил получит сюрприз. Я не думаю, что на аудиофильских трансформаторах (ценой в десяток обычных) кто-то станет экономить на меди ;) > Надо угадать с трансом. Для этого есть datasheet. >> Для классического БП: покупаем трансформатор (в datasheet есть все его данные), ставим >> диодный мост и конденсаторы. LDO по необходимости. Из приборов нужен только мультиметр. > А потом замечаем что транс не домотали и он дает импульсные помехи, ИМХО он раньше сгорит, чем кто-то успеет замерить эти помехи :) > LDO греется как печь. А без этого - он из стабилизации > выйдет, т.к. в сети может быть и 180 и 240. Зависит от требований. Многие схемы дорогих усилителей обходятся без LDO - просто детали ставят с запасом по напряжению. > И "сосед со сваркой" импульсником получще фильтруется. От соседа ИИП сам умрет и хорошо если сам аппарат не утянет. >> Самое обидное, что можно накосячить на любом этапе и не заметить :( > Однако осцил (и даже мультиметр понимающий ВЧ-переменку) спалят пульсации. Тем не менее - это дополнительные проблемы. Да и замеры нужно провести при всех вариантах нагрузки. И все равно остается шанс что-то упустить. > Не испытываю проблем с помехами импульсников, а брошенные в воздухе щупы сообщают > что 50Гц - доминируют. Но их давить нужно в любом случае. А для ИИП добавляются еще новые частоты. > Спору нет, телегу можно сделать и чуть ли не одним топором, > но что-то желающих это делать осталось немного. Зависит от задачи. Но да - ИИП лучше для большинства применений. > Любители emu и проч не очень плюются вроде, хотя там под > боком крутой импульсник. Некоторые dac/adc от emu1212m выносят из корпуса (благо там две платы и adc/dac и прочий аналог отделен от dsp) и питают от трансформаторного БП или вообще от аккумуляторов. > А что до надежности - посчитать импульсник так что он даже 380 > ("перекос фаз") выдержит, хоть без ограничений по времени работы. Практически везде стоят конденсаторы 400-450V на входе. 380 * 1.4 = 532V - фейерверк обеспечен. > А с классикой такие запасы надежности уже напряжны по габаритам/массе и > повсеместным запасам параметров, Включая и вторичку. Тем не менее, я разобрал 20-30 ламповых тв, отработали они не один десяток лет. У всех БП были живые. Да и многие тв были рабочими. А вот отказов ИИП я видел много. В первую очередь из-за входных конденсаторов - тяжелый режим работы для них в ИИП.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	163. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 14-Дек-16, 01:13
	> Нет, стандартный 24 MHz. И как вы из него 44100 делаете? То что 48000=24M/500 я догадался. > (или должны были быть ;) Это китайцы, аппнотой разве что ref des дешевого планшета. > Так а чего еще желать? В идеале по 1 PLL на железку, чтобы не греть мозг pll sharing :P. > alsamixer крутили (громкости/mute/переключатели)? Повключал очевидное, громкости поднял. Звука нет. А если пульс запустить и потом в hw0 или pcm.real играть - работает. > Было бы интересно весь ряд (32-96) таким образом прогнать Ок,надо файлики приготовить. > возможно mute аппаратно отключает выходной усилитель. ИМХО там power gating по неактивности. > так как он сам монопольно занял устройство. 1) пульс отпускает девайс по таймауту. 2) официальное апи этой системы - пульс, так что. > Все программа тупо должны отсылать все в устройство "default". На нокии невозможность использования алсы по дефолту - гарантирует использование пульса апликушниками. И отсутствие алсапроблем. > Все остальные решения принимает alsa. А чтобы в виджете выбрать вместо вывода в уши вывод в FM TX - алса как поможет? С пульсом и дбас я еще догадываюсь как это может быть. > При том весьма гибко - ресемплинг и dmix вставляется при необходимости 1) На смарте гибко это перекинуть аудио с динамиков в FM tx. На лету. По нажатию кнопки в виджете. Без затыкания плеера и остального. 2) Если бы в алсе сразу был dmix (MANDATORY!) и упрощенное апи для "проиграть анонс" - может этими пользовались бы без костылей типа пульса. > Если пользователь указал использование hw, значит ему нужен прямой доступ к железу На смарте это НЕ пользовательский уровень. Да и на писюке тоже. > (для минимальной задержки/минимальной нагрузки/запуска аудиосервера/измерения качества звуковой платы). Это вторично. Поэтому я и считаю что хорошо сбалансированы технические и менежерские вещи. И получился Продукт. Настолько эпичный что я не знаю чем его заменять. Юзабилити смарта и дебиан как начинка - уникальное сочетание. > Если это сделал маинтейнер пакета - это признак профнепригодности. Профнепригодность (в project management) это оптимизация смарта на страдание хней вместо базовых юзкейсов. > проще вообще вызвать готовый плеер. Такие "апи" мне не требутся. > Pidgin вообще тянет за собой gstreamer, вот уж действительно overkill. Pidgin умеет voip и видеозвонки IIRC. Упомянутого "апи" для этого маловато будет. > Но зачем? Alsa его делает сама (алгоритм/качество - на выбор). Я не знаю какое rationale, но оно работает так. И результат порой ужасен. > player, game, etc) и выводить каждый класс программ в свое устройство со своей громкостью. А теперь "фантомас в очках на аэроплане": переключаем потоки на лету. Я жму кнопку в виджете. Звук перекидывается с динамиков на FM tx. Работает N900 так. Здесь и сейчас. Все это non-stop. Плеер не затыкается. Звук пропадает в динамиках и тут же появляется через радио. Я не уверен что с девайсами такой номер катит. "Девайсы" наверное не подрзазумевают что "плеер" можно перекинуть с "боковые динамики" на "FM TX" на ходу? Или как это в терминах девайсов, алсы и чтобы не срубать софт? > нужен собственный регулятор - то проще его встроить в приложение Кому проще - тот пусть и встраивает, а мне проще пульсом пользоваться. > У данного кодека это реализовано на аппаратном уровне. 1. Чрезмерная завязка на возможности железки чревата вендорлоком. 2. Пульс позволил сделать "как надо" а не "как умеет железка". Имхо первична задача и имплементация а не изгибание под заскоки какой-то железки. > Это можно сделать и без dbus и pa - освободить память/cpu и > увеличить время автономной работы. Теоретически - можно и на луну слетать. Завтра. Практически - сделайте и покажите как это делать лучше. ИМХО шина с pub/sub туда удачно ложится. Получается молульная система, гибкая и мощная. Generic enough. Good enough. > А можно рулить через amixer/alsa api. И о чудо - без dbus :) Как без шины предлагается координировать части системы и сторонний софт между собой? Чтобы была заменяемость/дополняемость/модульность компонентов гуя и системы, софт мог знать what's going up, если его это интересовало, и т.п.? > На этом кодаке аппаратно можно делать почти все. Лучше сразу task-specific ASIC отлить. > ИМХО в данном случае Nokia урезала возможности, а не расширила. Нокия сделала конфигуряемую и модульную систему. За это я и люблю _компьютеры_. > Вы можете на N900 используя PA на динамик вывести звуки от игрушки > и параллельно музыку в наушники Но сначала 2-ю пару ушей отрастить. Иначе пойнт фичи не понятен. > а у музыки 44.1, но ресемплинга не будет нигде. Я или слушаю динамики, или наушники. И мне актуальнее например врубить в плеере трек на замену треку игры, etc, в ТОТ ЖЕ вывод. > (2 параллельных блока с большой функциональностью) существует. Нынче бывает много всяких весьма крутых чипов для самых разных задач. У техасцев чипы обычно навернуты. Не сказать бы grossly overengineer'нуты. > Не вижу технической проблемы. Зато я догадываюсь какие грабли UX и PM будут если сделать по вашему. Еще дедушка Кнут сказал что premature optimization корень всех зол. > Реализовано аппаратно. Тогда и ASIC вместо компа используйте. > Используя alsa + аппаратные возможности кодека можно сделать и более сложные вещи. Однако без системной шины и с привязкой к железяке - это вендорлок и влет на сотни кастом кодинга. PM FAIL. > Ничто не мешает включить adc при необходимости. Когда все в софте - битстрим можно немедленно ухватить или перенаправить. Проще, гибче, от чипа не зависит. /me считает что будущее за software defined системами. > так как прогоняем его через adc > pa > dac. Для fm не критично, но ... Да оно и для остального не критично. В целом сбалансированная система с хорошим UX. Это все-таки смарт, играющий в затычки (я купил получше дефолтных,но..). Не более пары часов в день. Экономия цать миллиамперов? Там экран лопает 200+ ма. И нивелирует экономию за 5 минут. Это ж не плеер чтобы в кармане валяться. У меня был хардкор более недели(аккумы подвели). А GPS на краю земли с OSM картами и маршрутом - мастхэв. Я экономил. Самый эффективный power management - яркость на минимум, сеть оффлайн. Еще частоту опроса GPS можно снизить, но это копейки. > Можно сделать и в alsa. Только судя по всему не реконфигурируемо и с граблями при желании динамически реагировать на внешние события. > Можно сделать и в alsa. Сделать можно все. Вопрос в потребных усилиях и как это будет выглядеть. > Реализовано аппаратно. Давайте я скажу что GPU меня заинтересовали лишь когда стал возможен GPGPU? > навороченные видеоплаты, но вместо использования их аппаратного ускорения, Современные видеокарты ушли от fixed function HW к массиву числодробилок. Железом подперты долбеж в провод и таскание блоков памяти. Может чего еще по мелочи. Большинство же вещей делается через шейдеры. > тупо все считаем на cpu и выводим все только через одну плату. Современные GPU для меня интересны массивом массово-параллельных числодробилок. Fixed function GPU для меня совершенно бесполезный и скучный артефакт. > Да - инженеры толковые. Глядя на этот девайс я говорю: "penguins can fly". >> и управленцы. > А вот с этими все не однозначно. Управление _проектом_ имхо на уровне, сбалансировано хорошо. А вот уровнем выше - да, там факапищи. > Да UX уделялось больше времени, чем оптимизации. И это нормально: 20ма экономии за день? Это 5 минут работы экрана. Экран, беспроводка и т.п. батарейку съедят быстрее. Если замечено что энергобюджет жмет, это прежде всего яркость на минимум. Но картинка страдает. > Но это не значит, что dbus и pa незаменимы и идеально подходят для данной задачи. Зато они: 1) Уже были - экономия на кодинге. 2) Нормально вписались в задачу. 3) Решений лучше на основе более-менее обычного линя я не вижу. ИМХО сбалансированный PM. > пусть и в ущерб потреблению ram/cpu/акб. Если гнать за идеалом - релиз программ сложнее hello world не состоится никогда. > В итоге при прослушивании музыки мы получим 14 бит вместо 16 :( Знаете, у PM'ов есть концепция "good enough". Вот N900 для меня - good enough. Он не самый крутой, не самый эффективный и все такое. Зато он все и сразу, гибкий, удобный и настраиваемый. > А на 100k? Да еще smd? :) Такой купить проще. Но если надо десяток ваттов рассеять - все меняется. > Верно, а в сложной тысячи деталей и у каждой свои вторичные параметры. Это проблемы производителя. Поэтому тратят усилия на костылирование, а потом характеризацию. А то что я получу описано в даташите. Еще в чипах соединения надежнее и меньше паразитных параметров. > ней багов. Они в основном мелкие, но иногда очень досадные. Да, но как кто-то сказал, "делать имеет смысл то что невозмозможно купить в магазине". > Возможно, но сейчас круг их применения очень широк - отсюда и большой ассортимент. У процессоров разница еще драматичнее, от фонарика до суперкомпьютеров. > Любой фильтр имеет свои конечные параметры. На 100+ кГц индуктивности и емкости физически мелкие. Можно несколько фильтров сделать. > Считается, что разрешение у аналогового тракта больше. Но на практике - сомневаюсь. Вот и я тоже. Изначально у технологии нет предпосылок для суперкачества. Если заапгрейдить, e.g.фотолитографией,на кремнии,по цене самолета..:) > что на ADC с >120 dB разрешением и открытие форточки влияет Запросто: изменится влажность и показания уплывут. Из-за паразитной проводимости. Надеюсь это объясняет почему я смотрю волком на заявления про 1 LSB@24 bit. > Но лучше тогда вынести обычный трансформаторный БП и питать всю аппаратуру постоянным током. Я не фанат трансформаторных БП. Огромные, материалоемкие, ХХ прожорливый, гудят и греются если мощные. > Так я и говорю - работают прилично работают до килогерцев. У электролитов ESR и ESL высокие, на килогерцах это перекосит параметры. И речь уже не про 0.01% искажений имхо. > В ИИП с этим хуже - там электролиты на входе и частоты большие. А не факт: 1) ИИП тасует энергию быстрее процессов усилка. Высоковольтный кондер можно считать немедленно доступным. 2) Кондеров на выходе с запасом по сравнению с циклом коммутации и временами регулирования. 3) Импульсники оперируют энергией нежели ее параметрами типа вольтажа. И поэтому эффективнее в откачивании энергии в неидеальных условиях. Импульсник меньше смущается e.g. просевшим вольтажом на входе. > Да и сами электролиты не любят быстрого разряда/заряда. Входной электролит импульсника работает в мягком режиме. Пульсации и токи небольшие т.к. напряжение высокое. Та же энергия означает меньший перекачиваемый заряд (и ток). > Для себя - да. Да и много керамики не нужно, так как есть еще и пленка. Хорошие параметры только у NP0. Остальное весьма компромисно. Если кто боится 0.01% THD, зависимости С от вольтажа и температуры ему явно не подарок, да и ESR/ESL. > электролитов столько, что усилитель играет еще некоторое время, после отключения питания. Это порой и про импульсники сказать. Энергия кондера C*U^2 и когда там более 300V, даже небольшой по мкФ кондер содержит много энергии. Хороший питальник компа не замечает провалы на 1-2 секунды. > Естественно нужно уменьшить ESR и ESL в максимально широком диапазоне. Скорее "equalizing". Если ставить 1 номинал - будет резонанс на некоей частоте. У всех компонентов кривая импеданс-частота одинакова, свойства цепи будут повторять ее. С разными компонентами кривые частично скомпенсируют друг друга. Свойства цепи в целом будут менее дурные. > Все, дошло :) Но тут другой момент - какой смысл мотать трансформатор > толстым проводом и малым количеством витков? Минимизация габаритов (витки) и нагрева (толщина). Если индуктивность может удерживать приложенное напряжение :). ВЧ транс меньше при равной мощности. > Проще намотать больше витков тонким проводом. По меди выйдет тоже, но не будет насыщения. Да, ХХ упадет. А нагрузить? Вся энергия снимаемая с вторички проходит первичку. Не забыв нагреть (P=I^2*R). Раз провод тонкий и его много, R ощутимый, I определяется снимаемой мощностью (+потерями). Опа! Транс с тонкой первичкой не может быть мощным. Тонкая первичка перегреется если из вторички много лопать. > Так трансформатор подбирается исходя из нагрузки. Это так. Но габаритная мощность 50Гц трансов низкая, а их дизайн это набор компромиссов. >> Большая катушка и так и сяк. > Пропорционально мощности. В ВЧ трансах отвал требования "много витков" глобально улучшает эти соотношения. Габаритная мощность выше на порядки. > В одном проекте я использовал на подобии этих: Ну, трансы. Мощность мизерная, цена невкусная, габариты характерные. > Да но тут есть соблазн экономить на феррите. По сравнению с 50Гц там дикая экономия на всем by design. От кондеров до меди. Сильнее сэкономить обламываются по перегреву сердечника. При попытке поднять частоты еще выше - греется сердечник. Перегрев фатален по любому поводу. Попадался "лайфхак": прижали сердечник через термо-керамику к экрану. Радиатор для сердечника, чо. Пойнт? Транс примерно как ваш на фото по размерам качал 100W. > Ибо я трансформаторы не мотаю, а использую готовые :) Проблема в том что капиталисты - хитрые типы. Норовят сэкономить. > Тем не менее, я так и не нашел в гугле таких осциллограмм. Я не помню где их видел, в какой-то книжке по трансам или профильных изданиях, имхо. > Да и в любом случае такие трансформаторы легко определить по току ХХ и нагреву. Высокие моментальные значения не обязывают средние сильно увеличиться, если они кратковременны. Заметно становится лишь при значительном наглеже. Алсо зависит от вольтажа сети. Проверять имеет смысл на максимальном который бывает в энной сети. И тут большой вопрос какие design goal были и какие margins оставили, if any. Медь дорогая. > Я не думаю, что на аудиофильских трансформаторах (ценой в десяток обычных) Это да. Но капиталисты жадины. > Для этого есть datasheet. В даташите обычно не описывают такие детали. Где для ваших трансов ну хотя-бы ток ХХ? >> А потом замечаем что транс не домотали и он дает импульсные помехи, > ИМХО он раньше сгорит, чем кто-то успеет замерить эти помехи :) Тепловые дела инерционны. Кратковременный прострел трансу не вредит. Чтобы выгорело надо сверхнагло сэкономить. А прострел - мало того что иголка с высоким dI/dt никак не синуса так еще транс в этот момент воздушная катушка. Поле не может более удерживаться в железе и разлетается как будто железа нет. Все данные для хорошего разлета. > Зависит от требований. Многие схемы дорогих усилителей обходятся без LDO - просто > детали ставят с запасом по напряжению. Только при этом появится зависимость от предыстории и отклик схемы будет ну совсем не идеальным отображением входа на выход. И наверное это не про 0.01% искажений. > От соседа ИИП сам умрет и хорошо если сам аппарат не утянет. С чего импульснику помирать? А так и сварочные ИИП бывают нынче :). > И все равно остается шанс что-то упустить. Я соглашусь что требования повыше. Но сделать ХОРОШИЙ питальник, давящий помехи из сети, без ripple, с стабильным напряжением и не создающий наводок - challenging задачка даже в классической топологии. > Но их давить нужно в любом случае. А для ИИП добавляются еще новые частоты. У ИИП хороший rejection входа, в отличие от. Контроллер регулирует быстро, 50Гц для него медленное изменение. В ИИП представление энергии на входе не критично, ИИП пытается накачать из "что есть" то "что хочется". Критерий - напряжение на выходе. И пока физически возможно откачивать из src достаточно энергии, процесс работает. > Зависит от задачи. Но да - ИИП лучше для большинства применений. Поэтому они и захватили мир :) > adc/dac и прочий аналог отделен от dsp) и питают от трансформаторного > БП или вообще от аккумуляторов. ИМХО это уже маньячество. Нефигово бы проверить на слепых тестах, статистически :P. > Практически везде стоят конденсаторы 400-450V на входе. 380 * 1.4 = 532V > - фейерверк обеспечен. 400-450V - долговременно выдерживаемое. Пиковое выше. И если вы о трансах для аудиофилов - так в импульснике тоже можно хоть керамики на киловольт вместо электролита набрать. > десяток лет. У всех БП были живые. Да и многие тв были рабочими. Смотря что понимать под живостью. Старые электролиты имеют свойство сохнуть и терять емкость/увеличивать ESR. Иногда могут даже деполяризоваться если много лет не включались (впрочем при включении частично самопочинатся). > А вот отказов ИИП я видел много. В первую очередь из-за входных конденсаторов > - тяжелый режим работы для них в ИИП. У входных он относительно нормальный, убитый сетевой кондер я видел лишь 1 раз и у того вывод отвалился. Возможно вы про ВЫХОДНЫЕ? Вот эти мрут как мухи, там режим жесткий. Нынче им удобно донавесить кучу емкой керамики в помощь (если не заменить их таковой совсем) и питальник будет условно-вечным :)
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	32. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Led (ok) on 11-Ноя-16, 04:21
	> В порядке увеличения потребления: wav, flac, mp3, vorbis, opus. Не факт. wav и, возможно, flac за счёт ширины потока могут "энергопотреблять" больше.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	45. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 11:25
	В какой конкретно ситуации? Пред тем, как отправить данные на DAC их все равно приходится распаковывать в PCM и потока ширина соответственно выравнивается. Остается разница только в сложности алгоритмов распаковки - для wav/pcm она близка к нулю, остальные сложнее.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	66. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 15:30
	В ситуации чтения с диска. Разве I/O - не энергозатратная операция?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	70. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Ноя-16, 17:29
	Трудно точно сказать - нужно делать замеры. Но ИМХО процессор при декодировании ест больше, чем micro sd читающая wav. С hdd ситуация несколько сложнее - там файлы сперва читаются в буфер, затем винт останавливается. Если буфер большой - то без разницы, так как винт в любом случае проснется из-за действий пользователя. Если малый - то будет чаще просыпаться и быстрее посадит акб.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	85. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 20:17
	> Трудно точно сказать - нужно делать замеры. Но ИМХО процессор при декодировании > ест больше, чем micro sd читающая wav. Вот это весьма зависит от. У N900 например I/O с NAND и SD почему-то очень дорогое по ... нагрузке на CPU. Может дойти до того что сжать файл LZO и записать его - и быстрее и проц меньше грузит за счет уменьшения IO. Если файл конечно сжался.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	91. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 02:21
	> Вот это весьма зависит от. У N900 например I/O с NAND и > SD почему-то очень дорогое по ... нагрузке на CPU. Крайне странно - cpu должен спать, пока dma сливает данные. Вероятно система неадекватно показывает нагрузку cpu. Или не используется dma - что еще более странно.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	107. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 12-Ноя-16, 21:52
	> Крайне странно - cpu должен спать, пока dma сливает данные. Вероятно система > неадекватно показывает нагрузку cpu. Или не используется dma - что еще > более странно. Нет, CPU не спит. Он при активном ворочании данных как раз занят в полку и в него все и упирается - если его разогнать, IO ускорится. Я не исследовал с чем именно это связано, но данность такова что на этой системе оно почему-то вот так. И если mp3 врядли станет более энергоемким из-за io то вот flac наверное уже может. Системы быавют разные и у них бывают разные свойства. Иногда странные или дурацкие.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	111. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 13-Ноя-16, 03:24
	> Иногда странные или дурацкие. Если только так, но в любом случае - это не нормально. Я такого даже на soc не видел, не говоря уж о полноценных системах. Все же посмотрите драйвера - очень уж напоминает, как на первых-вторых пнях винты тормозили и проц ели, пока нормальный драйвер с dma не накатишь. Может и акб будет существенно дольше жить.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	116. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 13-Ноя-16, 19:43
	> Если только так, но в любом случае - это не нормально. Ну вот есть такая система. И есть такая данность в этой системе. Можно ли это сделать лучше я хз. Если бы все было тривиально - имхо это сделали бы много лет назад чуваки из nokia или ti. > Я такого даже на soc не видел, не говоря уж о полноценных системах. OMAP оверинженернутый донельзя, именно этот еще и "недружественный". У OMAP есть IOMMU. Есть secure mode. Есть большой ROM, в т.ч. невидимая secure часть, доступная только из secure world. В secure world смертных техас не пускает. Решили они так. Это "secure part" в понимании техаса, там все через ж. Ядро - в гостях. Оно не может взять и сделать. На пути между ядром и железом, да и железом и железом IOMMU. Многие части чипа доступны только из secure world, в том числе и конфиг IOMMU вроде. Вместо прямого доступа ядро должно вызвать secure monitor из того неведомого ROM и просить его сделать желаемое. Если тот согласен. Там даже secure boot есть. Бутлоадер подписан. Но нокия решила что можно грузить неподписанные ядра, т.к. пробный шар. Это их решение отвинтить 1 гайку. Многие иные гайки в "нокиесмартфонском" состоянии. Описание секурити фич OMAP не существует. Техас это под nda дает. А "смертным" продают non-secure варианты. Где secure mode якобы недоступен, в результате части управления процом вообще отпали. И там есть какие-то костыли с таки вызовом, таки того же secure rom, которого как бы "нет", ага. Возможно что этот оверинжиниринг что-то где-то нагнул, зарубив доступ или создав оверхед. > Все же посмотрите драйвера - очень уж напоминает, как на первых-вторых пнях > винты тормозили и проц ели, пока нормальный драйвер с dma не накатишь. Это возможно, НО в конкретно этом архаичном high-secure OMAP даже простые вещи зачастую оказываются сложными или невозможными. И я не горю желанием детально тыкать палочкой дико оверинженернутый и недружественный чип давно снятый с производства. Я не планирую иметь дело с OMAP в будущем, догадайтесь почему ;). У ti еще и цены на чипы конские, а horsepower никакой. > Может и акб будет существенно дольше жить. Если девайс просто лежит без использования беспроводок и прочего - он живет более недели. Ток при этом что-то типа 4 ма. Если что народ там врубился что там charge manager, даташит нашел. Все это по i2c доступно. Можно невозбранно читать многие энергетические дела. Это же и "fuel gauge" касается. Офф: кстати, это вы спрашивали что бывает на CAN в современных авто? Хороший пример попался https://geektimes.ru/post/282338/ - человек реверснул топологию от и до, ессно это валидно только для его конкретного авто. Но я бы назвал это "CAN reversing definitive guide".
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 14-Ноя-16, 04:07
	> Если девайс просто лежит без использования беспроводок и прочего - он живет > более недели. Ток при этом что-то типа 4 ма. Недурно. > Офф: кстати, это вы спрашивали что бывает на CAN в современных авто? > Хороший пример попался https://geektimes.ru/post/282338/ - человек реверснул топологию > от и до, ессно это валидно только для его конкретного авто. > Но я бы назвал это "CAN reversing definitive guide". Спасибо, гляну.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	124. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-16, 04:49
	> Недурно. Нокия много с этим бодалась. И это себя окупило. Этот ток не включает активность беспроводки и прочие эпизодические но энергоемкие процессы. И да, я не верю проприетарным алгоритмам меряющим 1900ма*ч на 1200 ма*ч батарее. И как минимум валидирую показания этих показометров. Показометров два + проверяется по времени работы от батареи в idle. Кстати раз уж у меня такой доступ в систему есть - наверное логично будет посмотреть на практике токи для разных форматов. И есть некоторые вещи которые мне не совсем очевидны. 1) При равном качестве, OPUS < Vorbis < MP3 по битрейту. Если битрейт ниже, данных на обмолот меньше. А если менше молотить - меньше потребление. Вы как меряли? С прицелом на равный битрейт? Равное качество? Или чего? 2) При VBR, потребление не будет константой и будет зависеть от содержимого композиции. 3) Разные уровни громкости немного меняют потребляемый ток. Откуда логичный вывод что содержимое композиции влияет на ток как минимум через битрейт выбираемый кодеком и громкость. Если навскидку, без претензий на точность и научность, один и тот же трек с jamendo в mp3 и vorbis (оба варианта кодировали они), общесистемно по цифрам из fuel gauge - примерно так: mp3    (55±6) ma vorbis (51±6) ma Т.е. vorbis на этом девайсе оказался даже чуть экономичнее почему-то, но разница - в пределах погрешности.  Добавочная проверка: значения и погрешности стыкуются с показаниями чипа charger manager.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	127. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 15-Ноя-16, 12:30
	> 1) При равном качестве, OPUS < Vorbis < MP3 по битрейту. Если > битрейт ниже, данных на обмолот меньше. А если менше молотить - > меньше потребление. Вы как меряли? С прицелом на равный битрейт? Да, равный битрейт (192). И вы правы, если ориентироваться на качество - разница между lossy (mp3/opus) будет меньше. Но в тоже время больше при сравнении с lossless. > 2) При VBR, потребление не будет константой и будет зависеть от содержимого > композиции. Сжимался один и тот же фрагмент. > Т.е. vorbis на этом девайсе оказался даже чуть экономичнее почему-то, но разница > - в пределах погрешности. ИМХО с vorbis есть какой-то нюанс. Иногда он потребляет меньше mp3, иногда больше. Вероятно зависит от содержимого композиции и в некоторых случаях задействуются "тяжелые" алгоритмы.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	133. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 17-Ноя-16, 21:14
	> Да, равный битрейт (192). Сильные кодеки могут позволить себе меньше битрейта, что уменьшает сложность декодирования. Это как mpeg2 vs vp9/h.26x - первый конечно легче декодировать на том же битрейте, но для сравнимой картинки битрейт придется накинуть опять же в разы. И если h.26x и vp9 500kbps @ 720p еще и смотреть можно, то от mpeg2 с такими параметрами глаза вытекут. > И вы правы, если ориентироваться на качество - разница между lossy (mp3/opus)будет меньше. У меня на "идентичном" треке ворбис даже чуть-чуть выиграл. Т.е. среднее потребление при проигрывании ворбиса было чуть ниже . Это "real-world example" - треки кодировал один и тот же сервис (если верить хидерам и тэгам, q7 vorbis и 192kbps VBR mp3). > Но в тоже время больше при сравнении с lossless. Формально у lossy и lossless не может быть равное качество :P. > Сжимался один и тот же фрагмент. Это то понятно, но как там кодеки битрейт распределяют и насколько это (не)удачно - отдельный вопрос. И по хорошему фрагментов должно бы быть несколько. Но да, объективно померять свойства кодека - имхо ни разу не тривиальное начинание. > ИМХО с vorbis есть какой-то нюанс. Иногда он потребляет меньше mp3, иногда больше. Не совсем древние ворбисы (в которые включили наработки AoTuV, а это было давно) имхо в целом значительно более сильный кодек чем мп3. На 96 кбит ворбиса - я отличаю от оригинала с трудом, на 128 - зачастую не могу отличить совсем. Может быть бывают особо неудачные композиции, где это более заметно, но мп3 на 128 кбит вообще слушать невозможно. И поэтому я бы ставил vorbis в один ряд не с mp3 а где-то между aac-lc и aac-he наверное. А opus заткнул даже he и поднял планку. Настолько, что я не могу так с наскока назвать кодек который мог бы попытаться это переплюнуть. > Вероятно зависит от содержимого композиции и в некоторых случаях задействуются > "тяжелые" алгоритмы. Я вполне допускаю что кодеки не всегда хорошо угадывают. По мнению Matt Mahoney оптимальное сжатие данных вообще AI-hard проблема.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	87. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Led (ok) on 11-Ноя-16, 22:57
	> В какой конкретно ситуации? Пред тем, как отправить данные на DAC их > все равно приходится распаковывать в PCM и потока ширина соответственно выравнивается. А перед всем этим их нужно считать с носителя.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	98. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 14:58
	Провел замеры на sansa clip zip. Непосредственно декодирование mp3 ест 2.4 мА. Чтение со встроенной flash памяти - 35 мА при скорости 7300 КБ/с. Для wav поток будет - 172 КБ/c. Затраты на чтение wav составят 35 / (7300 / 172) = 0.8 мА. Для mp3/320 поток будет - 40 КБ/c. Затраты на чтение mp3 составят 35 / (7300 / 40) = 0.2 мА. Складываем поток и декодирование: 0.2 + 2.4 = 2.6 мА. Итого wav обходится 0.8 мА, mp3 - 2.6 мА, Разница в 3.25 раза. Это конечно не значит, что плеер в три раза дольше будет играть при воспроизведении wav, так как нужно питать soc/dac/усилитель - но все же разница будет. И чем лучше оптимизирован soc и софт, тем больше будет разница.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	108. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 12-Ноя-16, 22:03
	> Для mp3/320 поток будет - 40 КБ/c. Затраты на чтение mp3 составят > 35 / (7300 / 40) = 0.2 мА. Это могут быть некорректные вычисления. Они предполагают что потребление состоит только из динамики, а есть еще статика и прочие фиксированные расходы. Скажем если готовый к работе чип трескает 10 ма из-за управлящей логики и утечек и он не успевает отвалиться в deep sleep с небольшим потреблением между чтениями - он может постоянно трескать свои 10 ма если его изредка дергать незначительными чтениями. А может и не трескать, если успевает отвалиться в low power. Ничему не противоречит.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	112. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 13-Ноя-16, 03:36
	>> Для mp3/320 поток будет - 40 КБ/c. Затраты на чтение mp3 составят >> 35 / (7300 / 40) = 0.2 мА. > Это могут быть некорректные вычисления. Они предполагают что потребление состоит только > из динамики, а есть еще статика и прочие фиксированные расходы. Я так и написал - это только декодирование mp3 + затраты на чтение. Статику я отбросил, она одинакова для обоих случаев и зависит от soc и софта. > Скажем если готовый к работе чип трескает 10 ма из-за управлящей логики > и утечек и он не успевает отвалиться в deep sleep с > небольшим потреблением между чтениями - он может постоянно трескать свои 10 > ма если его изредка дергать незначительными чтениями. Там большой буфер. В него читается из flash и затем flash отключается. А трескает проц, который декодирует и отсылает данные. Конкретно на этом soc выгоднее не использовать dma при работе с dac - так как там косяк с буфером - глючит на больших размерах, а на малых размерах - dma ест больше проца. Так или иначе все это я отбросил, так как нас интересовало - что затратнее i/o или декодирование.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	117. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 13-Ноя-16, 21:03
	> Я так и написал - это только декодирование 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-ы между размерами и временем звучания. Наиболее честный и очевидный способ - зарядить, закольцевать, померять через сколько срубится, и так для разных форматов. Вопрос с интегрированием импульсных процессов и оверхедом - решится сам, в виде максимально приближенном к реальности. Но это долго и не сказать что удобно. Зато сразу готовый ответ - во что на практике различие форматов отливается. А то что мы отбросили одно и оставили другое - ну хорошо, допустим, а какую практическую ценность это несет? Пользователь в конце концов получит на свою голову систему целиком, со ВСЕМ тамошним оверхедом и особенностями.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	121. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 14-Ноя-16, 05:09
	>> Я так и написал - это только декодирование mp3 + затраты на >> чтение. Статику я отбросил, она одинакова для обоих случаев и зависит от soc и софта. > Как вы сами же и померяли в вашем же смарте - нечто > типа статичного потребления и прочего может оказаться доминирующим. А вы его > отбрасывать? ИМХО так не годится, попахивает систематической ошибкой измерений. Еще раз речь шла о том - что затратнее: i/o или распаковка. Оба процесса - динамика. Статика неизменна. > Лично меня скорее интересует практический сценарий. А именно: есть некая система. Она > играет те или иные форматы. Для пользователя интересно сколько оно проживет > с неким форматом, чтобы понимать tradeoff-ы между размерами и временем звучания. Если интересует, полный расклад на сегодняшний день: idle (статика)  6.8 мА wav   8.5 мА flac  9.0 мА mp3   10.5 мА opus  11.1 мА + периодический переход на повышенную частоту - то есть реально больше По поводу динамики - уже сейчас мне известена проблема, решение которой позволит уменьшить потребление для всех кодеков (включая wav) на 1-1.5 мА. Что до статики - она относительно неплохо оптимизирована и выжать из нее больше, не жертвуя качеством звука, вряд ли получится. Если пожертвовать - можно уменьшить на 1-2 мА, но звук будет примерно как у среднего смарта. На момент, когда я присоединился к разработке rockbox, потребление было примерно в два раза больше (такое же как у оригинальной прошивки). В начале никто не верил, когда я выложил свои результаты, так как считали, что выжали из плеера все и столь большой разницы не может быть в принципе. Но потом разработчики и пользователи провели замеры - разряд полной акб с замером времени. Потом пошла работа по доведению для commit'a, доработки для работе на плеерах с аналогичных SoC. Я стал частью команды, а разработчики прислали мне еще плееров на похожем SoC, дабы я повторил результат :) Но все руки не доходят. Все это я к тому, что фокус с мультиметром дает быстрый и относительно точный результат. До меня все измерения проводились на время полного разряда акб, что как не позволяло выявить многие проблемы. Лучшим оказалось совместное использование - я работаю с мультиметром, пользователи проверяют на время разряда.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	125. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-16, 05:33
	> Еще раз речь шла о том - что затратнее: i/o или распаковка. А правильный ответ внезапно оказался "зависит от системы" ;). Т.е. на вашем SoC оно вот так. А на моей n900 - эдак. Цена IO в разных системах разная. > Оба процесса - динамика. Статика неизменна. Это факт. > idle (статика)  6.8 мА Я думал что такие SoC делают по достаточно дубовым процессам и утечки должны быть мизерными. Но если что - под статикой я понимаю то что под ней понимают разработчики чипов, т.е. потребление чипа когда вентили статичны, сугубо паразитные утечки. Затраты на постоянно существующие сигналы типа клоков - это в их терминах таки динамика. Даже если есть всегда. Они в терминах переключения вентилей оперируют. В современных чипах часто делают clock gating, снижающий эту часть динамического потребления (даже в STM32, с стартом "все off" что "доставляет" ардуинщикам). > wav   8.5 мА > flac  9.0 мА > mp3   10.5 мА > opus  11.1 мА + периодический переход на повышенную частоту - то > есть реально больше Хехе, моя нокла быстренько продула как только включила плеер :). Похоже у более крупной системы накладные расходы на сам факт что оно что-то делает - больше. > Что до статики - она относительно неплохо оптимизирована и выжать из нее > больше, не жертвуя качеством звука, вряд ли получится. А оно надо? Хотя это наверное от емкости аккмулятора зависит. С упомянутыми у меня токами N900 протянет более 20 часов. Учитывая что я обычно задалбываюсь часа за 3-4 слушания - это не основная статья расходов энергии. > стал частью команды, а разработчики прислали мне еще плееров на похожем > SoC, дабы я повторил результат :) Но все руки не доходят. А вы джедай, что ни говори :) > Все это я к тому, что фокус с мультиметром дает быстрый и относительно точный результат. Я бы сказал иначе. Это удобный трюк быстро проверить в правильную ли сторону идет процесс. Чем-то похоже на то как гугл видеокодек оптимизирует, только вместо мультиметра - метрики качества. Которые весьма показометричны и не очень отражают реальное восприятие двуногими, но позволяют двигать процесс более-менее в правильную сторону. Поэтому VP9 двухгодичной давности - не то же самое что свежая версия. > совместное использование - я работаю с мультиметром, пользователи проверяют на время разряда. Как по мне - у вас получился хороший и эффективный рабочий процесс в этом плане.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	128. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 15-Ноя-16, 13:01
	>> Еще раз речь шла о том - что затратнее: i/o или распаковка. > А правильный ответ внезапно оказался "зависит от системы" ;). Т.е. на вашем > SoC оно вот так. А на моей n900 - эдак. Цена > IO в разных системах разная. Соглашусь, если сказать "зависит от бажности системы" :) Все же ваш случай исключение, а не правило. Как вы определяете, что cpu используется при i/o? Если в консоли запустить cp (дабы исключить паразитную нагрузку от обновления графики), что показывает top (cpu: usr sys idle io)? >> idle (статика)  6.8 мА > Я думал что такие SoC делают по достаточно дубовым процессам и утечки > должны быть мизерными. Но если что - под статикой я понимаю > то что под ней понимают разработчики чипов, т.е. потребление чипа когда > вентили статичны, сугубо паразитные утечки. Затраты на постоянно существующие сигналы > типа клоков - это в их терминах таки динамика. Даже если > есть всегда. Они в терминах переключения вентилей оперируют. В современных чипах > часто делают clock gating, снижающий эту часть динамического потребления (даже в > STM32, с стартом "все off" что "доставляет" ардуинщикам). Ok, тогда это не статика, а просто idle - простой системы. Часть блоков функционирует, cpu вне глубоком сне. В этот состоянии (конкретно на этом SoC) мы не отключаем dac и усилитель, так как мы не можем полностью исключить щелчок при включении/отключении (там нет разделительных конденсаторов ухудшающих звучание и из-за этого такие проблемы). Так как это плеер и в паузе он находится не долго (глубокий сон не используется, загрузка плеера идет 1-2 сек), то это приемлемо. Если dac и усилитель отключить - будет менее 3 мА. >> wav   8.5 мА >> flac  9.0 мА >> mp3   10.5 мА >> opus  11.1 мА + периодический переход на повышенную частоту - то >> есть реально больше > Хехе, моя нокла быстренько продула как только включила плеер :). Похоже у > более крупной системы накладные расходы на сам факт что оно что-то > делает - больше. Да, тоже и с android. > А оно надо? Хотя это наверное от емкости аккмулятора зависит. У плееров они совсем мелкие, да и требования другие. Никто не хочет каждый день заряжать плеер. Раз в неделю-две или при закачке новой музыки - нормальное требование. > С упомянутыми > у меня токами N900 протянет более 20 часов. 1200 / 8.5 = 141 час для wav 1200 / 9 = 133 часа для flac 1200 / 10.5 = 114 часов для mp3 1200 / 12 = 100 часов для opus В реальности будет меньше - емкость акб садится, подсветка тоже периодически включается. > А вы джедай, что ни говори :) :) > Я бы сказал иначе. Это удобный трюк быстро проверить в правильную ли > сторону идет процесс. Чем-то похоже на то как гугл видеокодек оптимизирует, > только вместо мультиметра - метрики качества. Которые весьма показометричны и не > очень отражают реальное восприятие двуногими, но позволяют двигать процесс более-менее > в правильную сторону. Поэтому VP9 двухгодичной давности - не то же > самое что свежая версия. Да, похоже. >> совместное использование - я работаю с мультиметром, пользователи проверяют на время разряда. > Как по мне - у вас получился хороший и эффективный рабочий процесс > в этом плане. Спасибо на добром слове :)
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	134. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 18-Ноя-16, 00:45
	> Соглашусь, если сказать "зависит от бажности системы" :) Не любая особенность системы - баг. С практической точки зрения система работает, а IO в полку для смарта довольно редкий сценарий все-таки. Поэтому не основная статья расходов. Кстати нокия и power gating mmc запилила. И обтоптала развеселые баги когда карты transcend отрапортовав что все сделано - в фоне что-то делают и отключение питания приводт к развалу карты. Если б не перцы из нокии - линуксоиды откушали бы с лопаты непонятных развалов карт памяти в мобильных девайсах и проч, где mmc-host умеет power gating. > Все же ваш случай исключение, а не правило. Для того чтобы делать такие заявления - надо собирать статистику по вообще всему железу на планете. Железо бывает разное и порой странное. Это из области "20 заблуждений программистов о времени", имхо. > Как вы определяете, что cpu используется при i/o? В статусбаре висит виджет CPU и RAM. И top того же мнения. Если активно тасовать большие файлы, девайс греется в области проца. Косвенное подтверждение. > Если в консоли запустить cp (дабы исключить паразитную нагрузку > от обновления графики), что показывает top (cpu: usr sys idle io)? IO ведет себя одинаково с любой программой. С cp примерно 9-10% sys, 85-90% io, несколько процентов сам cp и 0-5% idle. Эффект присутствует и когда cp свалил и ядро уже скидывает буферы. Знаете, иногда бывает так что устройство становится логичным продолжением возможностей человека. Это один из тех случаев. Я знаю сколько оно сейчас лопает. И представляю сколько так может продолжаться. Я знаю не какие-то попугаи и проценты, а вольтаж, ток и остаток заряда по мнению менеджеров. После пары недель вдали от розетки я лучше любого чипа оценю перспективы и времена. И могу заставить девайс забить на шатдаун, если мне необходимы лишние полчаса работы любой ценой. Будет работать пока dc-dc в принципе дает достаточный для работы проца вольтаж. Я знаю на сколько метров врет мне gps здесь и сейчас. Я знаю что может и не может его камера. И чего ожидать от вафли. А ожидать от mac80211 можно и всякие ништяки, типа отдельного мониторный интерфейс с airodump-ng или там ad-hoc, который ведроидам почему-то обычно слабо. > этом SoC) мы не отключаем dac и усилитель, так как мы > не можем полностью исключить щелчок при включении/отключении Нокия усилок отключает, если аудио долго не игралось. Если знать что ищешь, можно услышать power gating усилка. Но он достаточно ненапряжный и редкий - я его несколько лет вообще не замечал. Возможно потому что слушаю музыку с n900 на улице и т.п. и не фанат колонок на уши при этом. > загрузка плеера идет 1-2 сек), то это приемлемо. Если dac и > усилитель отключить - будет менее 3 мА. Нокиевская логика кажется мне довольно удачным балансом - с одной стороны не щелкает между треками, с другой - бросить девайс на паузе хоть на полдня ни во что по энергии не отливается вроде. > Да, тоже и с android. Более разлапистые системы - оверхеда больше, имхо. > У плееров они совсем мелкие, да и требования другие. А, если так - там наверное критерии экономии все-таки злее. > 1200 / 12 = 100 часов для opus Это что за цифры? Если плееру аккум от смарта присоединить? А смысл? Аккум от смарта достаточно большой все-таки. На посмеяться - прием FM лопает аж (92±10) ма. Но все-равно это около 12 часов, при том что задолбает значительно быстрее. > В реальности будет меньше - емкость акб садится, подсветка тоже периодически включается. ИМХО зависит от тока. Если ток небольшой (в % от емкости) - даже древний литий ведет себя культурно. У лития внутреннее сопротивление растет со временем, но на малом токе это не важно. А на большом токе батарейка половину потратит на нагрев себя. > Спасибо на добром слове :) Наверное с десяток лет назад я бы стал фанатом такого проекта. Впрочем... впрочем у меня был n800 наверное года с 2008 чтоли. О он тоже играет и wav и aac, и mp3 и vorbis (отдельным кодеком, но все-таки). А для аудио по сети умел даже достаточно продвинутые по тем временам вещи типа iLBC. Speex и прочих opus тогда вроде еще не было (к вопросу о том кто и что в кодеках разрабатывал).
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	138. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 18-Ноя-16, 13:54
	> Не любая особенность системы - баг. Баг - это незадокументированная особенность :) >> Все же ваш случай исключение, а не правило. > Для того чтобы делать такие заявления - надо собирать статистику по вообще > всему железу на планете. Железо бывает разное и порой странное. Вы правы, но как я уже сказал, на сотни железок, которые я ковырял, проблема была только на первых пнях и лечилась драйверами, откуда и вывод, что если подобное и существует - то скорее это баг или невозможность использовать/отсутствие dma. >> Если в консоли запустить cp (дабы исключить паразитную нагрузку >> от обновления графики), что показывает top (cpu: usr sys idle io)? > IO ведет себя одинаково с любой программой. С cp примерно 9-10% sys, > 85-90% io, несколько процентов сам cp и 0-5% idle. Эффект присутствует > и когда cp свалил и ядро уже скидывает буферы. Как я и предположил, вы не корректно определяете загруженность cpu. Если коротко - во время io wait, cpu делает тоже, что и во время idle - то есть ничего. Вас ввела в заблуждение странная методика подсчета idle в linux. Высокий io wait всего лишь означает, что система находится в ожидании окончания операции io. Есть отличная статья по теме, с подробным разъяснением, как так получилось, фрагментами кода ядра и наглядными примерами:   http://www.embedded-bits.co.uk/2015/understanding-io-wait-wh.../ > если мне необходимы лишние полчаса работы любой ценой. Будет работать пока >> этом SoC) мы не отключаем dac и усилитель, так как мы >> не можем полностью исключить щелчок при включении/отключении > Нокия усилок отключает, если аудио долго не игралось. Если знать что ищешь, > можно услышать power gating усилка. Мы в rockbox поступаем аналогично - если плеер не используется более 10 мин (пользователь может поставить другое время) - гасим не только dac но и весь плеер ;) >> 1200 / 12 = 100 часов для opus > Это что за цифры? Если плееру аккум от смарта присоединить? А смысл? > Аккум от смарта достаточно большой все-таки. Это я о энергоэффективности смартов. ИМХО ненормально жрать в пять раз больше, даже с поправкой на более тяжелую систему. > На посмеяться - прием FM лопает аж (92±10) ма. Но все-равно это > около 12 часов, при том что задолбает значительно быстрее. Да, это было бы смешно - но на clip zip радио тоже ест в двое больше, чем воспроизведение файлов. С чем это связано я толком не разбирался, но похоже особенность самого радио чипа. > ИМХО зависит от тока. Если ток небольшой (в % от емкости) - > даже древний литий ведет себя культурно. У лития внутреннее сопротивление растет > со временем, но на малом токе это не важно. А на > большом токе батарейка половину потратит на нагрев себя. Интересная мысль. Есть ссылки? А то с ходу не нашел.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	143. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 20-Ноя-16, 18:36
	> Баг - это незадокументированная особенность :) В данном случае особенность как минимум известна мне. Да и я задокументировал немало "особенностей" в багтрекеры, что не делало их менее бажными само по себе :P. > и вывод, что если подобное и существует - то скорее это > баг или невозможность использовать/отсутствие dma. А этот тезис для каких классов/семейств систем проверялся? А так то теоретически я с этой точкой зрения согласен. Практически почему-то нередко попадаются железки где IO не такой уж и дешевый. В WL500GP например при тяжелой активности сети проц в полку из-за softirq. Конечно там проц более слабый и SDR RAM, но все-же. А что до DMA - представляете себе что такое trust zone controller + iommu и чем плох boot ROM, который и встает первым в эти тапки, настроив доступы так что много периферии доступно только в secure mode, secure monitor-у? В роли secure monitor назначается secure ROM чипа. Мало того что недокументированный, так у нокий ROM еще и кастомизирован под них. У ядра нет доступа в secure mode и в заметную часть периферии. В ARM самый привилегированный режим - secure mode. В этой системе в него не пускают, сделав lockout до запуска остального софта. Рассказывать про DMA в такой системе - это здорово, ага. Но я могу представить сколько там грабель. Кстати этот ваш MSM в смарте тоже не подарок. > - во время io wait, cpu делает тоже, что и во время idle - то есть ничего. Как минимум, из того что я вижу - это время проца вроде бы недоступно остальным программам для использования, а проц изрядно греется. > Вас ввела в заблуждение странная методика подсчета idle в linux. В *этой* системе странностей может быть значительно больше, хотя-бы потому что есть secure monitor. А как немолодое ядро может учитывать допустим время потраченное на нечто типа "hypercalls"? > Высокий io wait всего лишь означает, что система находится в ожидании окончания операции io. Я не смотрел как именно этот драйвер сделан, но в столь долбанутой системе в хучшем случае может оказаться что "ожидание IO" может быть и чем-то типа вызова secure monitor. Возврата из которого придется "подождать" чисто технически, примерно как возврат из прерывания. Из очевидного что я видел недавно в ядре применительно к этому чипу: акселератор AES ядру недоступен. Потому что конфигурится как secure периферия и может использоваться только secure monitor-ом. В secure mode его отпиливает вроде как бутлоадер - кто-то даже ухитрился это отпатчить, видимо на тот кусок бутлоадера уже не распостраняется секурбут. А часть периферии обрубается прямо ROM'ом - это вообще оспорить нельзя. > Есть отличная статья по теме, с подробным разъяснением, как так получилось, Боюсь что для именно _этой_ системы многие привычные вещи вообще неприменимы. Если вам так удобнее - можете считать что ряд операций с периферией делаются путем неких hypercall-ов в hypervisor. Система двинута на секурити и многие вещи там нельзя просто взять и сделать. Ядро там довольно-таки в гостях у secure mode который чем-то похож на hypervisor по смыслу. И все это нихрена не документировано. В общем расписываться за то что делает эта система имхо можно только после весьма основательного изучения как там и что. Если вам что-то говорит BB5, технически это оно, с послаблением только в том что в энный момент загрузчиком забивается на секурбут на апликушном проце. Остальные стандартные нокиевские приколы BB5 на месте. > мин (пользователь может поставить другое время) - гасим не только dac > но и весь плеер ;) Ну для смарта - совсем загасить смарт будет все-таки плохой идеей. Там система грузится долго, утрата работоспособности неприемлима да и загрузка - очень энергоемкий процесс. Так что попытки экономить батарею телефонов путем их выключения зачастую дают обратный результат - одна перезагрузка может слопать больше чем многие часы standby. >> Аккум от смарта достаточно большой все-таки. > Это я о энергоэффективности смартов. ИМХО ненормально жрать в пять раз больше, > даже с поправкой на более тяжелую систему. У SoC и вообще системы смарта все-таки значительно больше обвеса и там более агрессивная оптимизация на скорость. У CMOS процессов существуют оптимизаци на скорость или на потребление. ARM даже попробовал скрестить ежа и ужа в big.LITTLE по этому поводу, чтобы в одном чипе были и low power ядра для малых нагрузок и скоростные - для высоких. > я толком не разбирался, но похоже особенность самого радио чипа. Вот и у меня такое ощущение что это чип радио столько трескает. Тем более что в этом чипе еще и блютус интегрирован. >> большом токе батарейка половину потратит на нагрев себя. > Интересная мысль. Есть ссылки? А то с ходу не нашел. Есть некоторое количество экспериментов с литийионом и старинные аккумы. Экземплярам которые барахлили в девайсах я взял да и померял внутреннее сопротивление "дифференциально" - по изменению напряжения под разными нагрузками. У нескольких совсем древних дошло до 1.5 Ома. Телефоны с такими аккумами могут начать вырубаться при звонке. Довольно характерный failure mode. Просто потому что однажды сопротивление батарейки растет настолько что на входе менеджера питания напряжение обваливается ниже критичного - из аккума с 1.5 Ома невозможно откачать пару ампер для звонка. По той же причине казалось бы полный аккум может стать "пустым" мгновенно (в этом случае вольтаж в коротком импульсе просел до порога warning менеджера питания). А в режиме ожидания - лежит себе уйму времени. Такие аккумы прекрасно работают в чем-нибудь слаботочном, не сильно меньше новых. Если заряжать и разряжать токами порядка 1C - такие аккумы ощутимо греются на внутреннем сопротивлении. И при заряде и при разряде. Кстати, греть литий выше 60 градусов - не стоит, иначе можно снять ролик для ютуба. Разумеется аккумы с нормальным внутренним сопротивлением - не греются при тех же токах. Чистая физика. Иногда бывают и другие проблемы. Посаженный ниже 2.5V литий - может развить сильные утечки или вспухнуть. Если это случилось, лучше выкинуть. Потому что поврежденный сепаратор и коротыш - опять же заявка на ролик для ютуба. У сильно циклированных могут дендриты из лития собраться (эти эффекты IIRC описаны у всяких электронщиков и в вике). Опять же по утечкам можно заметить. Если это долго игнорить - однажды может отлиться в коротыш и всем что за этим последует. Разок я чуть не подорвал старую банку 18650 - у нее внутреннее сопротивление было высокое а я врубил заряд обычным зарядником который полтора ампера дает. Банка разогрелась так что в руках еле-еле держать можно. Еще немного нагрева - и была бы пиротехника. Иногда доходит до смешного - при заряде приличным током древние аккумы почти сразу переходят в фазу CV.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	144. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 20-Ноя-16, 18:52
	> В данном случае особенность как минимум известна мне. Да и я задокументировал > немало "особенностей" в багтрекеры, что не делало их менее бажными само > по себе :P. Баг репорт конкретно на этот баг есть? > Практически почему-то нередко попадаются железки > где IO не такой уж и дешевый. В WL500GP например при > тяжелой активности сети проц в полку из-за softirq. Сетевой io сам по себе более затратный. Я и на PC видел, как локалка довольно серьезно грузит CPU. >> - во время io wait, cpu делает тоже, что и во время idle - то есть ничего. > Как минимум, из того что я вижу - это время проца вроде > бы недоступно остальным программам для использования, а проц изрядно греется. Это легко проверить - запускает cp или dd - получаете большой io wait. Запускает задачу, которая не требует io, но способна занять весь cpu, с низким приоритетом. Смотрите сколько процентов cpu уходит на задачу с низким приоритетом. Подобный пример был в конце статьи.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	145. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 21-Ноя-16, 07:19
	> Баг репорт конкретно на этот баг есть? На девайсе кернел 2.6.28 - по нему баги разве что в Спортлото. Майнлайн там загрузить можно, поддержка железки в целом есть. НО есть нюансы. Наиболее скверный - PowerVR и его блободрайвер. Imagination кст уже догадался о симпатиях, на форониксе их PRщик нарвался на shitstorm и они аж искали разработчиков открытых дров. Чудаки. Рассказали что помогут переехать в Англию, но забыли спеки выложить. Как они себе это представляют? > Сетевой io сам по себе более затратный. Я и на PC видел, > как локалка довольно серьезно грузит CPU. У PC AFAIK значительно хуже с прерываниями чем у мелочи. Хотя на WL500GP тоже прерывания все грузят. > Это легко проверить - запускает cp или dd - получаете большой io > wait. Запускает задачу, которая не требует io, но способна занять весь > cpu, с низким приоритетом. Смотрите сколько процентов cpu уходит на задачу > с низким приоритетом. Подобный пример был в конце статьи. У них там какой-то очень оригинальный пример. В том плане что у них их же демонстрационная задача - проседает буквально в разы, они радостно показывают что немного циклов из iowait удалось извлечь. Ок, хорошо, из iowait можно извлечь сколько-то циклов, но все-таки, в их примере задача просела, как я понимаю, в 6 раз?! На нокии проседает поменьше, раза в 2.5 "всего". А если вспомнить изначальный вопрос - нас интересовало "насколько io грузит проц". И в конечном итоге - "сколько электричества это жрет". Я ради интереса померял: dd /dev/mmcblk в /dev/null вызывает потребление аж (230±20) ма. И, наверное, это все-таки вообще совсем не idle системы.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	147. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 21-Ноя-16, 12:26
	>> Баг репорт конкретно на этот баг есть? > На девайсе кернел 2.6.28 - по нему баги разве что в Спортлото. Сообщество n900 вроде до сих пор живо. Да и неужели за столько лет никто не озаботился? > Майнлайн там загрузить можно, поддержка железки в целом есть. Это дает шанс проверить исправлена ли проблема, если исправлена - бэкпортировать в 2.6.28. > У них там какой-то очень оригинальный пример. Это точно :) > В том плане что у > них их же демонстрационная задача - проседает буквально в разы, они > радостно показывают что немного циклов из iowait удалось извлечь. Ок, хорошо, > из iowait можно извлечь сколько-то циклов, но все-таки, в их примере > задача просела, как я понимаю, в 6 раз?! Ну не в 6, а в 3. У них 48% io был - соответственно только половина cpu свободна. Вторая проблема - sys как был 18% так и остался. Но вырос sirq с 32% до 81%. Очевидно, что такого не должно быть. Так как для random у них было 100% sys. Что точно не так - неясно. Возможно там как-то криво многозадачность реализована. Или их хак с добавлением задержки в драйвер привел к неадекватным результатам.   > На нокии проседает > поменьше, раза в 2.5 "всего". 1. Посмотрите сколько у вас занимает io, без параллельной нагрузки cpu. 2. Попробуйте другую нагрузку cpu, которая вообще никак не обращается к фс во время исполнения. > А если вспомнить изначальный вопрос - нас интересовало "насколько io грузит проц". > И в конечном итоге - "сколько электричества это жрет". Я ради > интереса померял: dd /dev/mmcblk в /dev/null вызывает потребление аж (230±20) ма. > И, наверное, это все-таки вообще совсем не idle системы. Какая при этом получилась скорость чтения?
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	148. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 22-Ноя-16, 12:43
	> Сообщество n900 вроде до сих пор живо. Ну да. Однако не думаю что кто-то захочет с 2.6.28 копаться. Майнлайн пилят. Но у него свои проблемы. Я не очень понимаю с каким юзермодом его потом используют - штатный софт подразумевает работающее 3D. > Да и неужели за столько лет никто не озаботился? ИМХО если бы все было просто - сделала бы еще Нокия при разработке. > Это дает шанс проверить исправлена ли проблема, если исправлена - бэкпортировать в 2.6.28. На именно нокии эксперименты с новыми ядрами по ряду причин достаточно достаточно утомительны. С 2.6.28 сменилась целая эпоха. Грубый прикидон показывает что это залет на разборки с бутлоадером (NOLO использует старый протокол и не DTB-aware) и наверное сборку своего рутфса (то что штатный взлетит с новым ядром - имхо не факт). > Ну не в 6, а в 3. Я с точки зрения времени работы их тестовой задачи. Без IO она закончилась в 6 раз быстрее. Значит IO в их примере оказалось совсем не халявным по CPU. > Вторая проблема - sys как был 18% так и остался. Но вырос > sirq с 32% до 81%. Очевидно, что такого не должно быть. Кстати, cp с флешки на флешку (т.е.чтение+запись) выглядит ощутимо иначе чем dd с флешки в null (т.е. чтение). При cp - появляется iowait. При dd вникуда - процентов 20 CPU даже может быть idle, а основной потребитель cpu - sys. Такое ощущение что запись и чтение ощутимо разные по свойствам. Сильно долбить немолодой флеш тестовыми записями мне не хочется - что я буду делать если он помрет? :) > Так как для random у них было 100% sys. Это наверное логично - ядро впахивает генерируя PRNGом поток рандома? > Что точно не так - неясно. Возможно там как-то криво многозадачность реализована. А как это с DVFS-рм дружит? А то 100% cpu на разных частотах - разные. Если задачи недостаточно для подъема частоты - она не померяется в "тощих" процентах CPU - на пониженной частоте? Или ядро достаточно умное для какого-то масштабирования? > Или их хак с добавлением задержки в драйвер привел к неадекватным результатам. Больше всего похоже на то что в целом IO у них совсем не халявное по CPU. А то что какие-то циклы из iowait извлечь можно - ну ок. > 1. Посмотрите сколько у вас занимает io, без параллельной нагрузки cpu. Говорю же - много. Если cp - проц в полку, с упомянутым iowait и проч. Если dd с чтением вникуда и большими блоками - может даже процентов 20 idle появиться, основной потребитель - sys. Если что 230 ма - для чтения dd'ом в /dev/null bs=1M померяно. > 2. Попробуйте другую нагрузку cpu, которая вообще никак не обращается к фс во время исполнения. Так я и попробовал этот их фокус с urandom - он вроде в cpu как раз и упирается. При IO он даже с нормальным приоритетом проседает в примерно 2.5 раза. Очевидный вывод - что IO в этой системе - никак не халява по циклам CPU. > Какая при этом получилась скорость чтения? С внутренней emmc до 20 мегов в секунду. С карты - зависит от карты. Запись разумеется медленнее (может оттуда и берется iowait?).
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	149. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 22-Ноя-16, 14:43
	> ИМХО если бы все было просто - сделала бы еще Нокия при > разработке. ИМХО она и сделала. > Значит IO в их примере оказалось > совсем не халявным по CPU. Он был халявный: "CPU:   7% usr  88% sys   0% nic   0% idle   4% io   0% irq   0% sirq" и упирался в скорость cpu. Потом они снизили в MMC driver clock rate, да бы узким место сделать io. Потом добавили задержку в драйвер, для демонстрации ситуации тормозной/кривой драйвер. В итоге получили "CPU:   0% usr  18% sys   0% nic   0% idle  48% io   0% irq  32% sirq". >> Вторая проблема - sys как был 18% так и остался. Но вырос >> sirq с 32% до 81%. Очевидно, что такого не должно быть. > Кстати, cp с флешки на флешку (т.е.чтение+запись) выглядит ощутимо иначе чем dd > с флешки в null (т.е. чтение). При cp - появляется iowait. > При dd вникуда - процентов 20 CPU даже может быть idle, > а основной потребитель cpu - sys. Такое ощущение что запись и > чтение ощутимо разные по свойствам. Совершенно верно. Я упустил, что скорость чтения и записи будет совершенно разной и соответственно для чтения может быть узким местом cpu, а для записи - io. > А как это с DVFS-рм дружит? А то 100% cpu на разных > частотах - разные. Если задачи недостаточно для подъема частоты - она > не померяется в "тощих" процентах CPU - на пониженной частоте? Или > ядро достаточно умное для какого-то масштабирования? Да, там все как-то хитро подсчитывается (точно не вспомню - давно читал) и показания строятся так, как если бы cpu работал всегда на полной скорости. Иначе была бы ситуация - реальная нагрузка снижается, а показания top растут - админы бы застрелились. > Запись разумеется медленнее (может оттуда и берется iowait?). Совершенно верно! Финал детективной истории: 1. Если io реально быстрый - то узким местом становится cpu. Что отлично согласуется с вашими наблюдениями, в том числе и с нагревом процессора во время io и ускорением io при разгоне cpu. 2. Считаем сколько стоит io: При скорости 20 МБ/c мы тратим 230 мА. Для wav получим: 230 / (20 * 1024 / 172) = 1.93 mA. В реальности будет меньше - так как чтение wav не будет приводить к повышению частоты cpu и повышенному потреблению. Обычно все алгоритмы управления частотой ждут некоторое время пред переходом на другую частоту, таким образом короткие пики нагрузки игнорируются. 3. Нагрузка на cpu зависит еще и от способа чтения  - есть ли выравнивание и от размера блока чтения. Используя dd можно найти оптимальный bs по скорости чтения. 4. Полученный результат вполне неплохо соотносится с моим для clip zip. У clip zip получилось меньше, так как там io является узким местом и процессор работал на минимальной частоте. Так же там используется выравнивание и большой размер блока чтения.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	156. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 27-Ноя-16, 19:11
	> ИМХО она и сделала. Однако в целом IO на этой системе достаточно дорогое, имхо. > Он был халявный: Странная какая-то халява все-таки. Особенно на нокии. >> Такое ощущение что запись и чтение ощутимо разные по свойствам. > Совершенно верно. Я упустил, что скорость чтения и записи будет совершенно разной Для флеша такое различие - обычное дело. Я бы наверное мог бы и раньше догадаться, т.к. кухню флеша неплохо знаю. > и соответственно для чтения может быть узким местом cpu, а для записи - io. Действительно, так понятнее в чем фокус. > Да, там все как-то хитро подсчитывается (точно не вспомню - давно читал) > и показания строятся так, как если бы cpu работал всегда на полной скорости. Вообще, логично. Я на всякий случай уточнил. А load avg я надеюсь это тоже касается? :) > показания top растут - админы бы застрелились. Ну да :) >> Запись разумеется медленнее (может оттуда и берется iowait?). > Совершенно верно! Финал детективной истории: Ну да, > 1. Если io реально быстрый - то узким местом становится cpu. Что > отлично согласуется с вашими наблюдениями, в том числе и с нагревом > процессора во время io и ускорением io при разгоне cpu. Вообще, звучит логично. Хотя сами по себе 20 мегов в секунду для такого ARN - не так уж и много на самом деле. > 2. Считаем сколько стоит io: > При скорости 20 МБ/c мы тратим 230 мА. Для wav получим: 230 > / (20 * 1024 / 172) = 1.93 mA. В реальности > будет меньше - так как чтение wav не будет приводить к > повышению частоты cpu и повышенному потреблению. Или больше. Потому что для чтения надо: 1) включить eMMC (и, возможно блок контроллера оной в omap), 2) дать все потребные клоки А частота может и повыситься. У кого-то из governor даже такой tunable припоминается как повышать частоту при IO. Помогает вкостылить скорость IO на системах где иначе IO тормозит т.к. проц не разгоняется. А когда IO прекратится - пока dvfs прочухает, пока таймауты отключения блоков наступят и что там еще. Блок не имеет смысл отключать если к нему обращение вскоре ожидается: включение блоков сопряжено с некоей латенси. Она конечно не гигантская но и не ноль. А жизня научила нокию не срубать питание карточкам сразу после того как те отрапортовали что все готово. Были прецеденты дестроя карт и нокия чинила всю подсистему mmc в линухе. Этот фикс наверное всем разъехался у кого mmc хост есть. Хоть и снижает энергоэффективность, но дестрой транслятора на карте памяти воспринимается юзерами гораздо хуже. Хоть это и баг карт на самом деле. Говоря за себя я не считаю линейное масштабирование чем-то априори-валидным для процессов с подобными свойствами. Все это имхо проверять надо. > Обычно все алгоритмы управления частотой ждут некоторое время пред переходом > на другую частоту, таким образом короткие пики нагрузки игнорируются. И правильно делают, потому что латенси всего этого - не ноль. Сначала надо ведь скомандовать power manager поднять вольтаж, подождать пока импульсник этот вольтаж фактически накачает, и только тогда станет безопасно выставить новую частоту. Это работает и в обратную сторону до некоторой степени. С той разницей что свалить на низкую частоту с повышенным вольтажом ничем не чревато, поэтому можно и не ждать. А вот как показали натурные эксперименты, агрессивный power gating карт памяти - очень даже отливается. > 3. Нагрузка на cpu зависит еще и от способа чтения  - > есть ли выравнивание и от размера блока чтения. Используя dd можно > найти оптимальный bs по скорости чтения. У флеша скорость чтения может зависеть еще и от того как это стыкуется с размером блока флеша и проч. Но я думаю что bs=1M был как минимум близким к оптимуму. Потому что вытаскивание одного такого блока - это образение сразу к большой куче страниц последовательно. Большинство других вариантов будет менее удачно. > и процессор работал на минимальной частоте. Так же там используется выравнивание > и большой размер блока чтения. ИМХО с bs=1M выравнивание вышло само по себе. В том плане что при этом оверхед на все остальное будет небольшой а основная масса операций будет удобной для флеша. Вообще с флешом обращать на выравнивание больше смысла при записи. Если блоки ФС попадут на пересечения страниц флеша - будет полный трэш по скорости записи. Да и операции неплохо бы выравнивать не только по страницам но и по erase block, но они большие а истинную геометрию флехи - как максимум ее можно прикинуть. Еще в новых картах сделали discard вроде, но я не думаю что eMMC 2009 года это умеет. А значит при записи она всегда будет залетать на erase (длительная по времени штука) до того как сможет program.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	30. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от SampleID on 11-Ноя-16, 03:53
	> А чуваки из гугля вот тут на днях сказали что бандвиз Пруф?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "В Fedora добавлена встроенная поддержка MP3"	+2 +/–
	Сообщение от mvg on 11-Ноя-16, 01:08
	> патенты на него почти закончились > (точнее - закончились везде кроме Штатов) Я тут читал, что все патенты, связанные с декодированием mp3, истекли (даже в США) ещё в сентябре 2015. Поэтому в любые плееры можно уже год встраивать поддержку воспроизведения mp3-аудио без всяких лицензионных отчислений и юридических ограничений. А оставшиеся патенты на mp3 связаны с технологией кодирования. Но и они уже истекут везде в следующем году.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	58. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Crazy Alex (ok) on 11-Ноя-16, 15:16
	Именно так, но это означает, что в федору всё равно пришлось пока бы пихать кодирование обходным путём. С точки зрения поддержки - проще и декодер вместе с ним, а не тащить отдельный пакет и возиться с тем, как что и где будет использоваться.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	26. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 01:48
	> Кодек как кодек. Его в своё время до ума довели, суперсжатие сейчас > не актуально, патенты на него почти закончились (точнее - закончились везде > кроме Штатов) так что, в принципе, абсолютно нормлаьный вариант Гугл подсказывает что устарел он сильно и ogg обгоняет его по качеству и сжатию. И не забываем, что он проприетарный! Кака в общем.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	64. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Crazy Alex (ok) on 11-Ноя-16, 15:24
	Ну, почитал. на 192 как никто ничего не отличал от оригинала, так и осталось. Проприетраность его практически закончилась даже там, где была. А распространённасть и поддержка железом - осталась. Ну, то есть у меня вообще в Musepack кое-какая музыка лежит (и он, кстати, по качеству получше того же Ogg) - но сейчас если бы я во что-то жал - это был бы mp3. Но я не стану - с лосслесс мороки меньше.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	67. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 15:54
	>на 192 как никто ничего не отличал от оригинала После встречи с медведем возможно… >Проприетраность его практически закончилась даже там, где была Вы бредите. Как был проприетарным так и остался. Проприетарность не проходит со временем
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	75. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от iPony on 11-Ноя-16, 18:12
	> на 192 как никто ничего не отличал от оригинала, так и осталось mp3-192? Нет, конечно. ЗЫ: Про mp3-320 есть такое. Но меньше не катит.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	126. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-16, 05:43
	> Ну, почитал. на 192 как никто ничего не отличал от оригинала, так и осталось. Если у тебя хорошие наушники и звуковуха - тебе не понравятся верхи на ударниках и иных агрессивных высокочастотных кусках. Mp3 очень уж гробит верхи и на 192 это все еще ощутимо. А vorbis ... ну я на 128 кбит уже перестаю замечать подвох. Opus - и того меньше. Т.е. если экономия места интересовала(а зачем еще надо lossy?) - поюзав opus можно уделать mp3 раза в два. А если место пофиг - lossless ессно лучше.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	65. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Crazy Alex (ok) on 11-Ноя-16, 15:27
	Да, ещё - Когда гуглите такие вещи - берите сравнения хотя бы от 2010 года и позже. А то в сети большинство древних материалов, и близко не соответствующих текущему состоянию вещей.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	89. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от anonymous (??) on 12-Ноя-16, 01:57
	> Кодек как кодек. Его в своё время до ума довели, суперсжатие сейчас > не актуально, патенты на него почти закончились (точнее - закончились везде > кроме Штатов) так что, в принципе, абсолютно нормлаьный вариант Отстойный кодек. Сливает по качеству более современным в диапазоне битрейтов до 256 кбит/с, и имеет определенные артефакты которые принципиально не устранимы даже на 320
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	92. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Mihail Zenkov (ok) on 12-Ноя-16, 02:36
	> и имеет определенные артефакты которые принципиально не устранимы даже на > 320 Какие? Есть пример, где артефакты хорошо различимы?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	109. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 12-Ноя-16, 22:06
	> Какие? Есть пример, где артефакты хорошо различимы? Не знаю как на 320 а на 128 VBR уши завянут от ваты на верхах. А теперь вообще попробуйте заметить артефакты в 64 кбит opus. А если слепым тестом? :)
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	131. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Аноним (??) on 17-Ноя-16, 12:49
	lossy компрессия должна умереть! Да здравствует Flac!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	152. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 23-Ноя-16, 14:52
	> lossy компрессия должна умереть! Да здравствует Flac! Мелко плаваее! Даешь нежатое видео в массы!
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

2. "В Fedora добавлена встроенная поддержка MP3"	+11 +/–
Сообщение от НовыйЮзер (ok) on 10-Ноя-16, 23:23
> добавлена встроенная поддержка MP3 Спасибо! Как будто на 15 лет назад %) xmms на gtk1...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "В Fedora добавлена встроенная поддержка MP3"	+4 +/–
Сообщение от Аноним (??) on 10-Ноя-16, 23:33
А это достижение?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "В Fedora добавлена встроенная поддержка MP3"	+4 +/–
	Сообщение от Аноним (??) on 10-Ноя-16, 23:45
	> А это достижение? Ага, поддержка mp3 была на первом месте в рейтинге пожеланий пользователей.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
Сообщение от Crazy Alex (ok) on 10-Ноя-16, 23:45
Кстати, везде кроме Штатов уже и патенты на mp3 проэкспайрились.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "В Fedora добавлена встроенная поддержка MP3"	+4 +/–
	Сообщение от Baz on 11-Ноя-16, 00:12
	Только хотел спросить - не истёк ли ещё патент .....
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "В Fedora добавлена встроенная поддержка MP3"	–2 +/–
Сообщение от Аноним (??) on 11-Ноя-16, 00:16
А чего fluendo обидели? Он как раз для GStreamer.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Аноним (??) on 11-Ноя-16, 00:49
Теперь вопрос знатокам: когда оставшиеся кодеки будут входить по умолчанию? Когда можно будет жить без посторонних репов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "В Fedora добавлена встроенная поддержка MP3"	+2 +/–
	Сообщение от Аноним (??) on 11-Ноя-16, 01:15
	Через 70 лет со дня смерти MPEG LA.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	27. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
	Сообщение от KOT040188 (ok) on 11-Ноя-16, 01:55
	Ответ: когда вымрут все проприетарные форматы => никогда…
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "В Fedora добавлена встроенная поддержка MP3"	+14 +/–
Сообщение от Аноним (??) on 11-Ноя-16, 00:50
Угарная новость для 2016 года, что ни говори.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "В Fedora добавлена встроенная поддержка MP3"	+8 +/–
	Сообщение от АнонимХ (ok) on 11-Ноя-16, 04:09
	Что должно показать, какие убогие могут быть правовые коллизии, создающие искусственные препятствия. Проприетарщина зло
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Лаин Кубер on 11-Ноя-16, 01:00
И не прошлои *-дцати лет
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от iCat (ok) on 11-Ноя-16, 06:51
Не верю!(с)Станиславский.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Аноним (??) on 11-Ноя-16, 10:00
Шел 2016-й год...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
	Сообщение от Профитмэн on 11-Ноя-16, 10:08
	То ли ещё будет 25 Октября 2017 года!
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	86. "В Fedora добавлена встроенная поддержка MP3"	+/–
	Сообщение от Аноним (??) on 11-Ноя-16, 21:58
	А что будет, двоичный формат отменят?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

42. "В Fedora добавлена встроенная поддержка MP3"	–1 +/–
Сообщение от anonimous on 11-Ноя-16, 10:36
Традиционное "там даже этого не было?".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Аноним (??) on 11-Ноя-16, 10:53
чем mpg123 от mad отличается?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "В Fedora добавлена встроенная поддержка MP3"	+1 +/–
Сообщение от Sound Master on 11-Ноя-16, 12:17
Новость отличная, хотя OGG все-равно лучше. За последние 2 года купил несколько дисков с классической музыкой, там среди прочего (mp3, flac, wav) были и OGG-файлики. Может это теперь стандарт индустрии?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

81. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Аноним (??) on 11-Ноя-16, 20:02
Кому не хватало? Зато релиз на неделю отложили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

164. "В Fedora добавлена встроенная поддержка MP3"	+/–
Сообщение от Илья (??) on 20-Мрт-17, 14:22
ой ну не знаю, я уже давно переполз на яндекс-музыку
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема