Ранее мы рассматривали фильтры, поведением которых, после старта, можно управлять лишь частично - вызывая предусмотренные в них методы. В этой статье мы создадим программируемый фильтр, поведение которого будет полностью определяться встроенной в него Lua-машиной, точнее загруженным в неё скриптом. Это позволит менять алгоритм работы фильтра без перекомпиляции исполняемого кода.

Код программ данной главы можно скачать с Github по ссылке:

https://github.com/chetverovod/Mediastreamer2_LuaFilter

Приступим к практической реализации. Для этого можно вспомнить как создается новый фильтр, см. главу 4. В этой схеме источником звукового сигнала может быть либо сигнал с линейного входа звуковой платы (sound_card_read) либо генератор DTMFсигнала (dtmf_generator). Далее данные попадают на вход разрабатываемого Luaфильтра (lua_filter), который осуществляет их преобразование в соответствии с загруженным в него скриптом. Затем данные поступают на разветвитель (Tee), который из входного потока образует две копии, которые выдает на два выхода. Один из этих потоков поступает на регистратор (recorder) и на звуковую карту для воспроизведения (sound_card_write). Регистратор (*recorder*), он сохраняет их на диск в формате raw (wavфайл без заголовка). Таким образом мы сможем прослушать и записать результат работы Lua-фильтра.

Продолжаем тему D-Bus на Хабре. D-Bus — система межпроцессного взаимодействия (IPC), которая позволяет приложениям в операционной системе сообщаться друг с другом. При этом приложения могут находиться на разных компьютерах.

Данная публикация является логическим продолжением переводов вводной статьи и cпецификации D-Bus. Она имеет уже практическую направленность, поскольку в ней рассказывается о том, как грамотно проектировать D-Bus интерфейсы. Будет показано как избежать промахов, которые обычно происходят, когда вы создаете свой первый, второй, третий D-Bus интерфейс.

Сегодня я публикую перевод доклада «An Examination of Open System Architectures for Avionics Systems– An Update» сделанного Joyce L. Tokar, PhD, Pyrrhus Software, LLC, в марте 2017.

Признавая необходимость доступных и эффективных решений для развития систем авионики, Министерство обороны США (Department of Defense, DoD ) в указаниях по повышению эффективности военных расходов (Better Buying Power 3.0, BBP), Инструкции 5000.02 и Руководстве по оборонным закупкам (Defense Acquisition Guidebook, DAG) призывает к использованию решений на базе Систем с отрытой архитектурой (Open System Architecture, OSA ). Цели руководства и указаний - избежать привязки к одному поставщику, сделать доступными развитие возможностей и /продвижение инноваций. В настоящее время осуществляются несколько инициатив по разработке стандартов OSA для использования в системах военной авионики. В этой статье будут рассмотрены три таких направления: Управление беспилотными системами (UxS ), Архитектура сегмента управления (UCS ), инициатива Открытые системы управления полетом (Open Mission Systems, OMS ) и реализация Перспективной среды авиационных бортовых систем (FACE​) выполненная открытой группой (Open Group). Эта статья начнется с уточнения определения систем с открытой архитектурой в понимании Министерства обороны США. Далее будет краткое описание этих трех стандартов OSA, мероприятий, которые проводятся в соответствии с указаниями Министерства обороны США. Документ затем представит анализ этих OSA на основе рекомендаций Министерства обороны США. И наконец, в документе будет обобщено состояние этих OSA и даны рекомендации для дальнейшей работы.

Аннотация

Программно-определяемые сети (SDN) - это развивающаяся парадигма сетевой архитектуры, которая фокусируется на разделении плоскостей управления и данных. SDN привлекают все большее внимание как со стороны академических так и промышленных кругов во множестве областей применения. В этой статье мы исследуем текущее состояние полученных знаний о военных SDN путем проведения систематизированного обзора литературы (SLR). В этой работе мы стремимся оценить текущее состояние дел с точки зрения путей исследований, публикаций, методов, тенденций и наиболее активных областей исследований. Соответственно, мы используем результаты для консолидации областей прошлых и текущих изысканий в указанной прикладной области, и предлагаем направления для будущих работ.

Ключевые слова

военные сети; виртуализация функций сети; SDN; программно-определяемые сети; программно-определяемое радио; систематизированный обзор литературы; опрос; тактические сети; беспроводные сенсорные сети

Эта публикация является переводом вводной части исследовательской работы объемом в 70 страниц, опубликованной в 2018 году. Поскольку объем значительный, то оставшаяся часть текста будет переведена только при наличии интереса со стороны хабравчан. Его вы можете выразить в голосовалке, размещенной ниже статьи или, на худой конец, лайками.

Аннотация

Программно-определяемые сети (SDN) - это развивающаяся парадигма сетевой архитектуры, которая фокусируется на разделении плоскостей управления и данных. SDN привлекают все большее внимание как со стороны академических так и промышленных кругов во множестве областей применения. В этой статье мы исследуем текущее состояние полученных знаний о военных SDN путем проведения систематизированного обзора литературы (SLR). В этой работе мы стремимся оценить текущее состояние дел с точки зрения путей исследований, публикаций, методов, тенденций и наиболее активных областей исследований. Соответственно, мы используем результаты для консолидации областей прошлых и текущих изысканий в указанной прикладной области, и предлагаем направления для будущих работ.

Ключевые слова

военные сети; виртуализация сетевых функций; SDN; программно-определяемые сети; программно-определяемое радио; систематизированный обзор литературы; опрос; тактические сети; беспроводные сенсорные сети

Уважаемые хабравчане, предлагаю вашему вниманию перевод оставшихся глав спецификации D-Bus. Полный pdf-документ можно скачать по адресу.

Поскольку перевод и верстка выполнялись в одно лицо, то наверняка найдутся ошибки и огрехи. Прошу сообщать об обнаруженных неточностях, чтобы я смог сделать перевод лучше и точнее. Пишите замечания либо здесь в комментариях, либо на адрес указанный в переводе. Авторы поправок, с их согласия, будут добавляться в дополнительный раздел документа, что-то вроде зала славы.

Спасибо за внимание.

Данная статья открывает серию публикаций с переводом спецификации D-Bus (Версия 0.36 от 2020-04-21). Поскольку у D-Bus нет логотипа, то в качестве обложки была использована картинка автобуса с D-образным корпусом. Для краткого введения в тему D-Bus рекомендую прочитать перевод обзорной статью написанной авторами D-Bus: https://habr.com/ru/post/529966/

Это вводная статья о технологии межпроцессного взаимодействия D-Bus, написанная его разработчиками. Дан краткий обзор ключевых моментов технологии. Рекомендуется читать перед изучением спецификации (русский перевод).

Здравствуйте, по материалам опубликованного мной ранее цикла статей, я подготовил pdf-файл, который представляет собой книгу с перекрестными ссылками, предметными указателями и т.д. В общей сложности 113 страниц.

Файл можно свободно скачать по ссылке: pdf-файл

Материал статьи взят с моего дзен-канала.

Все статьи цикла

Статья 1
Статья 2
Статья 3
Статья 4
Статья 5
Статья 6
Статья 7
Статья 8
Статья 9
Статья 10
Статья 11
Статья 12
Статья 13

Книгу на основе статей можно свободно скачать по ссылке: pdf-файл.

В прошлой статье, мы рассмотрели вопросы отладки крафтовых фильтров, связанные с перемещением данных.

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

Глава 7 Трассировка

7.1 История вопроса

Материал статьи взят с моего дзен-канала.

В прошлой статье, я обещал рассмотреть вопрос оценки нагрузки на тикер и способы борьбы с чррезмерной вычислительной нагрузкой в медиастримере. Но решил, что будет логичнее осветить вопросы отладки крафтовых фильтров, связанные с перемещением данных и уже потом рассмотреть вопросы оптимизации производительности.

Отладка крафтовых фильтров

После того, как мы в предыдущей статье рассмотрели механизм перемещения данных в медиастримере будет логично поговорить о скрывающихся в нем опасности. Одна из особенностей принципа "data flow" состоит в том, что выделение памяти из кучи происходит в фильтрах, которые находятся у истоков потока данных, а освобождение памяти с возвращением в кучу делают уже фильтры, расположенные в конце пути потока. Кроме этого, создание новых данных и их уничтожение может происходить где-то в промежуточных точках. В общем случае, освобождение памяти выполняет не тот фильтр, что создал блок данных.

Это статья посвящена тому, как использовать популярный инструмент рисования графов Graphviz в кооперации с препроцессором C/C++ (далее просто препроцессор).

Ключевым моментом является то, что язык описания графов dot, который использует Graphviz, по своему синтаксису пригоден для обработки препроцессором. Так задумано разработчиками. Благодаря их прозорливости, мы при описании графов можем использовать следующие возможности (цитирую википедию по памяти):

• замена соответствующих диграфов и триграфов на эквивалентные символы «#» и «\»;
• удаление экранированных символов перевода строки;
• замена строчных и блочных комментариев пустыми строками (с удалением окружающих пробелов и символов табуляции);
• вставка (включение) содержимого произвольного файла (#include);
• макроподстановки (#define);
• условная компиляция (#if, #ifdef, #elif, #else, #endif);

Теперь продемонстрируем открывшиеся возможности на практике. В качестве примера возьмем граф из моей статьи о Медиастримере2, он на рисунке ниже.

Материал статьи взят с моего дзен-канала.

Механизм перемещения данных

• Блок данных dblk_t
• Сообщение mblk_t
• Функции работы с сообщениями mblk_t
• Очередь queue_t
• Функции работы с очередями queue_t
• Соединение фильтров
• Сигнальная точка графа обработки данных
• Закулисная деятельность тикера
• Буферизатор MSBufferizer
• Функции работы с MSBufferizer

В прошлой статье мы разработали свой собственный фильтр. Эту статью мы посветим устройству внутреннего механизма перемещения данных между фильтрами медиастримера. Это позволит в дальнейшем писать изощренные фильтры с меньшими усилиями.

Материал статьи взят с моего дзен-канала.

В прошлой статье мы сделали дуплексное переговорное устройство, выполняющее обмен звуковым сигналом через дуплексную RTP-сессию. В этой статье мы научимся писать фильтры и добавим сделанный своими руками фильтр в сделанное своими руками переговорное устройство.

Разрабатываем плагин

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

Чтобы использовать плагин в своей программе, вы с помощью include должны подключить заголовочный файл плагина. В теле программы, с помощью функции у ms_filter_register() выполнить регистрацию нового фильтра. Естественно, ваша программа и и исходник плагина должны быть скомпилированы и собраны в одно приложение.

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

Материал статьи взят с моего дзен-канала.

Все статьи цикла

Статья 1
Статья 2
Статья 3
Статья 4
Статья 5
Статья 6
Статья 7
Статья 8
Статья 9
Статья 10
Статья 11
Статья 12
Статья 13

Книгу на основе статей можно свободно скачать по ссылке: pdf-файл.

Введение

Эта статья является началом цикла статей о реалтайм обработке медиаданных с помощью движка Mediastreamer2.

В ходе изложения будут задействованы минимальные навыки работы в терминале Linux и программирования на языке Си.

Mediastreamer2 это VoIP-движок, лежащий в основе популярного open-source проекта программного voip-телефона Linphone. В Linphone Mediastreamer2 реализует все функции связанные со звуком и видео. Подробный список возможностей движка можно увидеть на этой странице Mediastreamer. Исходный код находится здесь: GitLab.