Прикольно в GCC обстоят дела с BE/LE. Сегодня пишут в рассылке про AlsaPlayer, что мои плугины для APE и WavPack выдают шум на выходе. Я сразу просек, что проблема с BE/LE, однако откуда она взялась?

Итак, у меня был блок кода, в котором я разворачиваю 16 бит так, как мне надо. Выглядел он так:

#ifdef __BIG_ENDIAN
#warning "BIG ENDIAN"
некий код
#else
#warning "LITTLE ENDIAN"
некий другой код
#endif

На powerpc все работает, выдавая "BIG ENDIAN", а на x86 я ожидал, что будет выдаваться "LITTLE ENDIAN". И было отчего, потому-что, мы можем проверить, что этот макрос на x86 не определен:

[petro@host-12-85 wv]$ cat /dev/null | gcc -E -dM -| grep -i end
[petro@host-12-85 wv]$ cat /dev/null | g++ -E -dM -| grep -i end
[petro@host-12-85 wv]$

Однако, собрав на x86-машинке, я увидел сообщение о "BIG ENDIAN". Задумался.

Перешел на powerpc-комп, поглядел, что там пишут:

[petro@Sulaco wv]$ cat /dev/null | gcc -E -dM -|grep -i end
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
[petro@Sulaco wv]$ cat /dev/null | g++ -E -dM -|grep -i end
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
[petro@Sulaco wv]$ 

Все на месте.
Плюнул и решил вместо __BIG_ENDIAN использовать __BIG_ENDIAN__ (добавлены два подчеркивания в конце), и все заработало, как и было задумано.

Загадочно мне это, но буду знать про такой прикол.

УПД обнаружил, что неправильно писал макрос - надо было _BIG_ENDIAN (с одним подчеркиванием в начале), однако непонятно, почему вообще тот блок компилировался.

Я в электроосле, торренте и иных местах стал находить наконец-то нормальное высококачественно видео и музыку - ну, если видео в HDTV (а не в устаревающем DVD-качестве) уже не новинка, то то, что я скачал сегодня - для меня новинка.

А скачал я сегодня известный альбом коллектива Pink Floyd под названием "Dark Side Of The Moon", да не просто, а в 24bit/96kHz 4.1-channel (1,7 гигабайта, кстати!). Все это лежало в Wavpack (это еще позвляет FLAC и TTA, вроде как - APE в пролете), и я с удивлением сообразил, что прослушать-то мне это нечем - мой самописный плугин к плейеру, который я использую, AlsaPlayer-у, написан мной так, что он подразумевает, что ему подсунут только 16bit/44.1 kHz 2.0-channel. ПРидется доработать...

Дорабатывать можно двумя путями - можно улучшить интерфейс плейера с ALSA, чтоб использовать встроенные возможности ALSA для даунсэмплинга и rate-conversion, а пожно прикрутить что-то к самому плугину (это проще, но и неправильнее архитектурно).

В общем будет мне теперь на вечерок забава :)

Был плугин для XMMS, который лежал на каком-то кривом хостинге, и я даже не мог его долго найти в исходниках, но таки нашел. FYI XMMS - это устаревающий Gtk1-плейер для *nix, а Gtk1 без зверских манипуляций заставить понимать русский не получится. Ну манипуляции не такие уж и зверские, но на Gtk1 все уж давно положили, а потому стоит ли вообще с ним колупаться? А вот Beep Media Player, это порт XMMS на Gtk2. Потихоньку портируются под него и плугины, но для Wavpack еще не спортировали, а сестрице слушать хочется не AlsaPlayer'ом, а Winamp'оподобной штукой.

Надо - значит надо. Были взяты исходники плугина для XMMS и была взята страничка, описывающая процесс портирования с gtk1 на gtk2. Удивительно, но удалось все сделать очень быстро. Всего пришлось

а) поменять include-файлы с xmms/что-то-там.h на bmp/что-то-там.h
б) autoconf-файлы я править не стал, т.к. не люблю копаться в этом древнем мусоре, а просто наколупал пятистрочный Makefile
в) в трех местах исправил создание диалоговых окон (как описано на вышеуказанной страничке)

Все.

А вот результат:

http://lemenkov.newmail.ru/other/bmp-wavpack/

УПД с R_PPC_REL24 разобрался.

У меня просто архитектура моей персоналки - PowerPC, т.е. Big Endian, а у всех - Little Endian (интересно, а как же раньше макинтошевцы жили? обходились без APE что-ли?). Поэтому мало кто обращал внимание на endianness, а надо было (я тоже на это забивал по правде говоря).

Но тут я узнал, что в версии mac-3.99-u4-b5 поправили все возможные проблемы с endianness, и я решил попробовать. Сразу не заработало - пришлось кое-что поправить в APE-плугине к моему любимому плейеру AlsaPlayer, да и из-за того, что ассемблерные вставки в APE-либе есть только для x86, то реалтайма не получается, даже для файлов, сжатых по профилю "Normal".

На самом деле, формат APE мертвеющий. Плохо переносим, не играет в силу ресурсоемкости декодера на мобильных устройствах (на моей полуторагигагерцовой машинке с PowerPC G4 и то не успевает вовремя, а прикиньте, что будет на каком-нибудь ARM'е или MIPS'е?), долго кодируется, неособо то и отличается от конкурентов по сжатию - почему в нем все еще выкладывают музыку? А еще у него плохая лицензия, мешающая его включить в ведущие Linux-дистры и предотвращающая opensource-программистов от его использования.

А еще у меня начал подыхать очередной винт (на нем у меня лежат ослиные временные файлы). Вот что ужасное он пишет в логи:

http://lemenkov.newmail.ru/other/messages.utf8.txt

Тов. 4ephbi@lj высказал правдоподобное предложение, что все дело в разогреве внутри корпуса. У меня и правда плохое охлаждение моей башни, а винтов много. Видимо с покупкой 400-гигового винта надо будет разжиться системой охлаждения, а то жалко почти 25 гигов терять (их же потом замучаешься закачивать вновь).

Сегодня впервые за недели три покатался на коньках - с непривычки немного устал. Завтра еще пойду.

Хорошо!
Все в lostless, конечно.

Однако у адудиоплейеров в Linux есть серьезные проблемы с декодированием разных форматов. Какие форматы мне нужны:

* mp3 (это понятно)
* ogg (тоже потионьку популяризируется)
* flac (свободный lostless формат)
* ape (кривая лицензия, а линуксоиды этого не любят, но очень популярен)
* wavpack (часто стал появляться в ed2k-ссылках)
* musepack (есть пара альбомов)
* ac3/a52 (может что-то найтись)
* alac и aac (продают в Apple iTunes вроде как - может стать популярным)
* realaudio (есть несколько записей)
* tta (очень выгодный формат - сжатие очень быстрое, а размеры такие-же, как и у ape, lostless)
* wma (есть недружные с г8оловой, которые используют этот закрытый формат)

ну и wav (через libsndfile/audiofile) конечно.

Если wav/mp3/ogg/flac играют все аудиплейеры, то с состальными возникают проблемы (например, я не видел wavpack-плугина для xmms, а этих файлов уже много в eDonkey). Я использую AlsaPlayer - плугины для ape/wavpack/tta я дня него написал, но в самом плейере есть недостатки, которые я еще не устранил.

Итак.

А вот буду я вам иногда рассказывать про то, как делают программную начинку систем цифрового дома.

Этой зимой взял паузу и ничем общественно-полезным не занимался. Пора это изменить. С удивлением узнал, что к почти идеальному аудиоплейеру для Unix-систем, AlsaPlayer'у нет еще одного нужного плугина - плугина для проигрывания WavPack-файлов. Это такой очередной алгоритм lostless-аудиокомпрессии. Что важно, так это то, что в отличие от Monkey's Audio, описание формата, sdk и демо-приложения раздаются под GPL (или LGPL?) лицензией, что позволило добиться включения WavPack в репозиторий Fedora Extras.

Для AlsaPlayer'а писать плугины несложно, а потому займусь этим. Я уже сделал для него пару плугинов - для проигрывания Monkey's Audio и для проигрывания TTA-аудио, правда в последнем не доделал кое-что за отсутствием стимула (несмотря на прогрессивность стандарта и заметное превосходство над конкурентами я так и не видел в элекроосле музыки в этом формате).

Вообще сейчас приходится много делать по работе, а потому дома совсем неохота что-то программировать, зато можно лежать на кровати, слушать, например Jazzanova или их европейских товарищей и фантазировать про разное - например про то, каким должен быть идеальный аудиоплейер. Я, в своем проекте многозонного аудиосервера (что такое аудиосервер, см. например на сайте Imerge)4 года назад использовал именно AlsaPlayer. Разумеется xmms, beep-media-player и их форки и "конкуренты" - это далеко не идеал. Кучи рюшечек, странные зависимости от половины Gnome, связанность ядра и GUI - это какая-то жалкая копия вендозных поделок. Из хороших вещей можно выделить alsaplayer и music-player-daemon. Между делом я слышал еще про какие-то плейеры, но запамятовал про них. Собственно этих двух вариантов достаточно.

Плейер состоит из ядра, которое коммутирует плугины ввода и вывода, подключает между ними плугины фильтров (например триггер на события, такие как "старт", "стоп", "окончание плейлиста", фильтр типа tee, для копирования потока в визуализационный интерфейс, если он вообще нужен конечно, в чем я сомневаюсь, и т.п.) и предоставляет библиотеку интерфейсов для написания GUI.

GUI общается с ядром необязательно с помощью импорта каких-то там C/Python/Java-интерфейсов, но и например, как я сделал, по TCP/IP, что позволяет сделать управление с КПК/смартфона/другого компьютера/веб-интерфейса. В этом смысле мне очень понравилась библиотека AlsaPlayer - понадобилось совсем мало, чтобы прикрутить к ней управление с WinCE-игрушки.

Внутри плейера треки характеризуются произвольным кол-вом каналов (огромный минус у AlsaPlayer), частотой дискретизации (необязательно 44100), адресом физического носителя (URI, физический файл - у AlsaPlayer в этом смысле не все ладно с сетью - он плохо умеет работать с оборвавшимися трансляциями, логический файл, например CUE-таблица), временем старта (если носитель является ссылкой на файл и время старта, например APL-файлы, CUE-таблицы), временем останова, метаинформацией (тэги, физический адрес, физическая и логическая информация), состоянием (играет, не играет, неизвестно, недоступен и т.п.)

Вывод звука - это отдельное дело. Сразу несем на свалку aRts, Esound, OSS, омерзительного монстра GStreamer (на него даже смотреть страшно, не то, что делать с ним что-нибудь), а глядим на Alsa, как на LowLevel-интерфейс, поверх которой бегает микшер/роутер Jack или (с чем я так толком и не разбирался) NAS или MAS. Отсюда вытекают две стратегии.

Во-1, мы можем все (и хранение звука, и декодирование его, и систему управления) реализовать на одном жирном сервере, где нибудь в подвале дома, к которому присоединяемся клиентами типа КПК/смартфонов/интеллектуальных ПДУ типа crestron, и с него выводим уже готовую музыку с многоканальной карты (или двух-трех) типа M-Audio Delta 44 по хорошему экранированному кабелю на усилители, расставленные по дому. Можно также бросить музыку на усилок поблизости, а с него раскидать уже прямо на колонки по комнатам. В таком случае юзеру будет нужен только интеллектуальный ПДУ, но тут надо многоканальный усилок, и проверить нет ли зверских наводок на кабели.

Во-2, мы можем музыку не декодируя кидать прямо на миникомпьютеры, расположенные в помещениях дома, а там уже декодировать. Плюсы - нет никаких наводок, т.к. гоним прямо цифру, а потому можно удаляться от центрального сервера на десятки метров без опаски за звук, центральный комп можно делать послабее, т.к. он не декодирует много потоков аудио за раз. Минусы - теоретически усложнение в управлении распределенной системой ЭВМ. Сложная система проще теряет стабильность. В случае катастрофы на центральном сервере вся система так и так приходит в непригодность.

Пробная система была реализована на одной карте M-Audio Delta 44 с восемью моно-каналами (т.е. 4 стерео-аудиозонами). Использовался промышленный компьютер с большим жестким диском. Управление осуществлялось по Wi-Fi 802.11b с клиентов, работающих под управлением WinCE на Compaq iPaq ранних моделей. Музыка хранилась в mp3. Все работало под Linux, разумеется.

Глядя на прошлое вижу, что кое-что надо было бы доделать. Тогда это было гораздо дешевле существовавших на рынке, редких аналогов. Сейчас аналоги есть и дешевле, чем раньше, но все они все-еще расчитаны на людей, имеющих неограниченный запас денег. А ведь "умный дом", это удобно, и было бы полезно обычному юзеру (не жильцу убогой совецкой хрущобы, а, например, владельцу townhouse). Все аналоги страдают одним и тем-же - плохой расширяемостью, использованием нестандартных закрытых технологий (фиг прикрутишь APE или тот же WavPack, а вот FLAC-системы уже появляются), из-за задержек в разработке устаревают до того, как выходят (жесткие диски малых обьемов, наркоманские операционные системы типа Microsoft WinXP) и т.п.

Вот недавно вышел FLAC 1.1.2 (кстати rpm для федоры еще не сделали) и на LORе, разумеется, замутили мощный пустопорожний флэйм.

http://www.linux.org.ru/jump-message.jsp?msgid=813468&lastmod=1109266404931

Но!

Но среди гор было найдено следующее:( что же я нашел? )

Imported event Original

Итак.
За сегодня разбирался отчего это Monkey's Audio codec 3.99 так странно себя ведет при проигрывании, декомпрессии или верификации файлов, сделанных версией 3.97. Оказалось, что ( жми сюда! )

Imported event Original