Итак.
А вот буду я вам иногда рассказывать про то, как делают программную начинку систем цифрового дома.
Этой зимой взял паузу и ничем общественно-полезным не занимался. Пора это изменить. С удивлением узнал, что к почти идеальному аудиоплейеру для 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) и т.п.
![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small}
