Протокол коммутации смеси мультимедийных данных для управления мультимедийными данными

Протокол коммутации смеси мультимедийных данных для управления мультимедийными данными

Иллюстрации

Показать все

Реферат

Уровень техники

Поскольку больше систем конференцсвязи начинают предлагать один или несколько потоков мультимедийных данных идентичного типа (например, видеоданных), то необходимо, чтобы клиенты конференцсвязи могли визуализировать несколько потоков, предлагаемых системами конференцсвязи, с возможностью взаимодействия. Механизмы, например группирование линий передачи мультимедийных данных SDP (протокол описания сеанса, описанный в RFC 4566) и мультимедийного содержимого SDP, также способствуют достижению этой цели. Однако, за исключением случаев, когда клиент конференцсвязи понимает контекст того, как эти потоки должны визуализироваться, клиенты конференцсвязи могут не уметь визуализировать потоки, о которых клиент не знает.

В обычной архитектуре устройства управления многосторонней связью (MCU) отсутствует такой эффективный, гибкий протокол для модификации смеси мультимедийных данных в микшере MCU, что субъекты могут передавать мультимедийные данные, как задано, или принимать мультимедийные данные, как задано, с течением времени. Одна рабочая группа работает над устранением вышеупомянутого недостатка посредством управления функциями микшера (например, "запуск диалогового окна", "ожидание DTMF", "воспроизведение этих мультимедийных данных" и т.д.). Однако попытки управления функциями микшера или их имитации тогда ограничены доступными функциональными возможностями.

Сущность изобретения

Далее представлена упрощенная сущность изобретения для обеспечения понимания сущности некоторых новых вариантов осуществления, описанных в этом документе. Эта сущность изобретения не является исчерпывающим обзором, и нет намерения идентифицировать ключевые/критические элементы (изобретения) или установить границы его объема. Ее единственной целью является представление некоторых концепций в упрощенном виде в качестве вступления к более подробному описанию, которое представлено ниже.

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

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

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

Краткое описание чертежей

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

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

На фиг.3 изображена альтернативная система для модификации режима алгоритма смешивания.

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

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

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

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

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

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

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

Подробное описание

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

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

На фиг.1 изображена машинно-реализуемая система 100 управления мультимедийными данными (media) для модификации режима алгоритма смешивания. Система 100 включает в себя один или несколько алгоритмов 102 смешивания микшера 104 мультимедийных данных для смешивания входных потоков 106 мультимедийных данных согласно одному или нескольким режимам 108 смешивания. Микшер 104 является логическим субъектом (entity), принимает набор потоков мультимедийных данных идентичного типа (например, аудиоданных), объединяет мультимедийные данные специфическим для типа способом и перераспределяет результат в один выход или множество выходов (например, участнику(ам) сеанса). Система 100 также включает в себя интерфейс 110 протокола, который включает в себя одну или несколько инструкций 112 для изменений режима 108 смешивания алгоритма(ов) 102 смешивания, для коммутации входных потоков 106 мультимедийных данных для вывода одного или нескольких конкретных выходных потоков 114 мультимедийных данных.

Одна или несколько инструкций 112 интерфейса 110 протокола обеспечивают модификацию алгоритмов 102 смешивания для воздействия на режим(-ы) 108 смешивания для однозначной идентификации потока мультимедийных данных, отправляемого в субъект, или однозначной идентификации потока мультимедийных данных, принимаемого из субъекта, для коммутации входных потоков мультимедийных данных в микшер мультимедийных данных в конкретный выходной поток без порта микшера или функций управления IP и для предоставления информации о коммутации субъекту согласно некоторой политике. Политика может быть политикой предприятия, создаваемой и устанавливаемой администратором, например.

Одна или несколько инструкций 112 интерфейса 110 протокола также обеспечивают изменение в участии сеанса в отношении участников с удалением, по меньшей мере, одного из многих основных участников из сеанса или добавлением нового участника к сеансу. Интерфейс 110 протокола включает в себя одну или несколько инструкций 112 для уведомления основных участников об изменении в участии в сеансе. Например, если основные участники A, B и C присутствуют в конференцсвязи, и участник A запросил просмотр видеопотока участника B, то участнику C не обеспечивают возможность знать то, что участник A наблюдает за участником B. Однако участнику B может быть обеспечена возможность знать, что участник A наблюдает за потоком мультимедийных данных участника B. Интерфейс 110 протокола включает в себя одну или несколько инструкций 112 для добавления входного потока мультимедийных данных нового участника к сеансу и для представления информации о субъекте нового участника основным участникам.

В одной реализации интерфейс 110 протокола включает в себя новый набор инструкций для взаимодействия с алгоритмами 102 смешивания для формирования режима(-ов) 108 смешивания. В альтернативной реализации одна или несколько инструкций 112 включают в себя расширения существующего набора управляющих элементов (controls) для формирования режима(-ов) 108 смешивания. Новый набор инструкций и/или расширений управляющих элементов основан на схеме, которая включает в себя один или несколько элементов схемы из маршрута (route), коммутации (wire) и фильтра (filter).

На фиг.2 изображена мультимедийная система 200, в которой устройство 202 управления мультимедийными данными включает в себя компонент 204 микшера мультимедийных данных для смешивания входных потоков согласно изменениям базовых алгоритмов смешивания. Здесь, компонент 204 микшера мультимедийных данных включает в себя два микшера: первый микшер 206 для приема входного(ых) потока(ов) 208 мультимедийных данных первого типа (например, аудиоданных) для коммутации (или маршрутизации) в выходной поток 210 мультимедийных данных идентичного типа и второй микшер 212 для приема входного(ых) потока(ов) 214 мультимедийных данных второго типа (например, видеоданных) для коммутации (или маршрутизации) в выходной поток 216 мультимедийных данных идентичного типа. Первый микшер 206 мультимедийных данных включает в себя первый алгоритм 218 смешивания для формирования первого режима 220 смешивания.

Пользователь может манипулировать первым алгоритмом 218 смешивания для изменения первого режима 220 смешивания через интерфейс 110 протокола при передаче одной или нескольких инструкций 112 в первый алгоритм 218 смешивания первого микшера 206 мультимедийных данных. Аналогично, второй микшер 212 мультимедийных данных включает в себя второй алгоритм 222 смешивания для формирования второго режима 224 смешивания. Пользователь может манипулировать вторым алгоритмом 222 смешивания для изменения второго режима 224 смешивания через интерфейс 110 протокола при передаче одной или нескольких инструкций 112 во второй алгоритм 222 смешивания второго микшера 212 мультимедийных данных.

Одна или несколько инструкций 112 обеспечивают модификацию алгоритмов 102 смешивания для коммутации входных потоков (208 и 214), как требуется. Одна или несколько инструкций 112 управляют режимом(-ами) (220 и 224) смешивания для однозначной идентификации потока мультимедийных данных, отправляемого в субъект, или однозначной идентификации потока мультимедийных данных, принимаемого из субъекта, для коммутации входных потоков мультимедийных данных в микшер мультимедийных данных в конкретный выходной поток без порта микшера или функций управления IP, и для предоставления информации о коммутации субъекту согласно некоторой политике.

Система 200 обеспечивает коммутацию одного входного потока (например, потока(ов) 208 и 214) из точки в точку, из точки во множество точек, из множества точек во множество точек и из множества точек в одну точку. Система 200 может использоваться как узел сети (например, сервер) и/или как клиент в клиентской вычислительной системе, например.

На фиг.3 изображена альтернативная система 300 для модификации режима алгоритма смешивания. Система 300 включает в себя устройство 302 управления мультимедийными данными, содержащее микшер 304 мультимедийных данных из приема входного потока 306 мультимедийных данных, и маршрутизацию входного потока 306 в выходной поток 308 мультимедийных данных согласно модифицированным режимам смешивания. Более конкретно, микшер 304 мультимедийных данных включает в себя алгоритм 310 смешивания аудиоданных для смешивания аудиоданных (во входном потоке) 306 и алгоритм 312 смешивания видеоданных для смешивания видеоданных (во входном потоке) 306 мультимедийных данных. Микшер 304 мультимедийных данных включает в себя интерфейс 110 протокола для обработки инструкций 112 протокола из интерфейса 314 управления. Другими словами, пользователь может взаимодействовать через интерфейс 314 управления для отправки одной или нескольких инструкций 112 через интерфейс 110 протокола для модификации базового алгоритма 310 смешивания аудиоданных и/или базового алгоритма 312 смешивания видеоданных.

Алгоритмы (310 и 312) смешивания формируют режимы смешивания, которые обрабатываются компонентом 316 маршрутизации для маршрутизации входного потока 306 мультимедийных данных в выходной поток 308 мультимедийных данных. Компонент 316 маршрутизации принимает и обрабатывает сформированный режим 318 смешивания аудиоданных из алгоритма 310 смешивания аудиоданных и режим 320 смешивания видеоданных из алгоритма 312 смешивания видеоданных. Другими словами, входной поток 306 мультимедийных данных может быть смешан с аудио- и/или видеосигналами для маршрутизации как смешанного выходного потока 308 мультимедийных данных в выходной субъект.

Компонент 322 политики принимает и обрабатывает одну или несколько политик, которые могут регулировать то, как должно выполняться смешивание, и будет ли смешивание выполняться на основе принимающего субъекта, пользователей-источников и т.д. Компонент 322 политики может включать в себя сервер политики сеанса, который управляет функционированием сеанса.

На фиг.4 изображен иллюстративный микшер 104 для коммутации входных потоков в выходные потоки на уровне алгоритма смешивания. Микшер 104 принимает входные (или вход-микшер (to-mixer)) потоки 400 мультимедийных данных и смешивает входные потоки 400 согласно алгоритму 310 смешивания видеоданных и алгоритму 320 смешивания аудиоданных для вывода выходных (или выход-микшер (from-mixer)) потоков 402 мультимедийных данных. Модификация алгоритмов (310 и 320) смешивания может происходить через интерфейс 110 протокола.

Входные потоки 400 могут идентифицироваться посредством идентификационной информации для пользователя и типа потока мультимедийных данных, например идентификатора пользователя (userID=xx) и идентификатора потока мультимедийных данных (ID=xx). В этом примере типы входного потока мультимедийных данных ID=30, ID=31 и ID=32 и userID=2 могут быть для основного аудиопотока, основного видеопотока и вторичного видеопотока второго участника сеанса (или оконечной точки (endpoint)) соответственно. Аналогично, типы входного потока мультимедийных данных ID=24 и ID=31 связаны с userID=3 для основного аудиопотока и основного видеопотока третьего участника сеанса (или оконечной точки) соответственно. Другие входные потоки 400 могут быть частью сеанса конференцсвязи.

Параметр "label" ("метка") идентифицирует поток мультимедийных данных в микшер 104 и из него. Как обозначено ранее, входные потоки 400 в микшер 104 (от конкретного пользователя и оконечной точки) идентифицируются по ID в модели данных конференцсвязи. Метка является уникальной во всей модели данных конференцсвязи. ID является уникальным внутри элемента мультимедийных данных оконечной точки в модели данных и формируется сервером конференцсвязи.

Будем считать, что label=10 является потоком, содержащим смесь аудиопотоков из всех входных аудиопотоков, предлагаемых каждому участнику сеанса, label=11 включает в себя смесь видеоданных, и что label=12 является чередующейся смесью видеопотков, которая активизируется голосом. Микшер 104 смешивает входящие видеопотки 400 от участников в оба выходных потока label=12 и label=11. Это является одним примером модели микшера, другие модели микшера могут интерпретировать входные потоки по-другому. Однако введение интерфейса 110 протокола обеспечивает модификацию алгоритмов смешивания согласно раскрытой архитектуре. Интерфейс 110 протокола может принимать изменение или модификации алгоритмов (310 и 320) смешивания посредством XML, например, и/или команд CCCP (centralized conference control protocol, протокол управления централизованной конференцсвязью).

На фиг.5 изображено иллюстративное определение 500 схемы для протокола, который может получать доступ к режиму смешивания и модифицировать его в базовых алгоритмах смешивания. Определение 500 схемы может быть следующим. В одной реализации схема определяет новые расширения управляющих элементов (например, маршрут, коммутацию и фильтр) из управляющих элементов, которые определены в модели данных централизованной конференцсвязи (XCON). На недавно добавленные элементы к определению 500 схемы даны ссылки в нижеследующем структурном виде посредством "##", и они очерчены как 502 для ввода в микшер и 504 как выход микшера.

Ниже приведен ряд примеров, которые иллюстрируют способы, в которых архитектура протокола обеспечивает коммутацию мультимедийных данных. Данные, содержащиеся внутри такой схемы, представлены в следующем примере. Рассмотрим сеанс конференцсвязи с состоянием мультимедийных данных, изложенном ниже, для конференцсвязи sip:conf233@example.com, размещенной в MCU

.

<!-это является заданным по умолчанию потоком для foo@example.com-->

<!-это является потоком, где foo@example.com требует манипуляции смешивающимися маршрутами-->

<!-Примечание: Маршруты мультимедийных данных здесь не определены-->

<!-это является заданным по умолчанию потоком для foo@example.com->

Ниже приведен пример команды (команд) CCCP для модификации маршрута мультимедийных данных для участника. Будем считать, что субъекту sip:foo@example.com требуется модифицировать маршрут мультимедийных данных согласно потоку. Субъект может выполнять это посредством выдачи следующей команды CCCP "modifyEndpointMedia" (модифицировать мультимедийные данные оконечной точки). В следующем примере представлен запрос, который делает foo@example.com для приема потоков из bar1@contoso.com и bar2@fabrikam.com (Спецификация XMLNS опущена для удобочитаемости)

(здесь была спецификация xmlns)

<!-Примечание: Модифицированная таблица маршрутизации-->

Ответ может быть следующим:

(здесь была спецификация xmlns)

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

<!-Примечание: Модифицированная таблица маршрутизации в уведомлении C3P-->

В отношении опции упорядоченного опроса, если в отношении предыдущей опции уведомления учитываются размеры, и/или не существует возможности, чтобы система отфильтровывала элементы, которые требуют функций конфиденциальности, то может использоваться механизм упорядоченного опроса для извлечения маршрута коммутации. Упомянутый механизм возвращает список пользователей и оконечных точек (участников сеанса), которые наблюдают за конкретным потоком оконечной точки. В примере ниже иллюстрируется команда, которая может использоваться для извлечения состояния наблюдателя за мультимедийными данными для bar1@contoso.com и оконечной точки sip:bar1@contoso.com;gr=4940254792 с media id=56. Так как foo@example.com является единственным субъектом, наблюдающим за потоком, то возвращается информация об оконечной точке и субъекте этого пользователя.

(здесь была спецификация xmlns)

Ответ может быть следующим:

<!-Примечание: Не существует других элементов XML, возвращаемых под оконечной точкой или пользователем, или пользователями. -->

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

(здесь была спецификация xmlns)

<!-Примечание: Модифицированная таблица маршрутизации->

Ответ может быть следующим:

(здесь была спецификация xmlns)

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

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

Для адаптации опции уведомления Уведомитель (определенный в RFC 3265 и RFC 4353 как агент пользователя, который формирует запросы Уведомить с целью уведомления абонентов о состоянии ресурса) фильтрует определенные элементы, исходя из того, куда отправляется уведомление. Если конфиденциальность не учитывается, то Уведомитель может отправлять эту информацию всем участникам или может предпочесть совсем не отправлять информацию.

Ниже приведен ряд блок-схем, представляющих иллюстративные способы для выполнения новых аспектов раскрытой архитектуры. Несмотря на то, что, для простоты объяснения, один или несколько способов, изображенных в этом описании, например в виде блок-схемы или структурной схемы, изображены и описаны как последовательность действий, должно быть понято, что эти способы не ограничены порядком действий, так как некоторые действия, в соответствии с ними, могут происходить в порядке, отличном от порядка, изображенного и описанного в этом документе, и/или одновременно с другими действиями. Например, специалистам в данной области техники будет понятно, что в качестве альтернативы способ может быть представлен как последовательность таких взаимосвязанных состояний или событий, как в диаграмме состояний. Кроме того, не все действия, изображенные в способе, могут потребоваться для новой реализации.

На фиг.6 изображен способ управления потоками мультимедийных данных. На этапе 600 входной поток мультимедийных данных сеанса конференцсвязи коммутируется в оконечную точку согласно режиму смешивания, определяемому алгоритмом смешивания. На этапе 602 с использованием протокола инструкций получают доступ к алгоритму смешивания. На этапе 604 алгоритм смешивания изменяют с использованием протокола для повторной коммутации входного потока мультимедийных данных согласно новому режиму смешивания.

На фиг.7 изображен способ манипуляции базовыми алгоритмами смешивания микшера мультимедийных данных для повторной коммутации потоков мультимедийных данных сеанса. На этапе 700 с использованием протокола можно получить доступ к базовому(ым) алгоритму(ам) смешивания. На этапе 702 с использованием протокола может быть однозначно идентифицирован входной поток, отправляемый в оконечную точку или принимаемый из оконечной точки. На этапе 704, по выбору, повторно задают коммутацию входного потока мультимедийных данных оконечной точки на выходе для включения смеси других входных потоков (из) других оконечных точек без функций, связанных с портами и данными IP, с использованием протокола. На этапе 706, по выбору, задают коммутацию входного потока мультимедийных данных оконечной точки в конкретные выходные потоки мультимедийных данных соответствующих оконечных точек с использованием протокола.

На фиг.8 изображен способ манипуляции базовыми алгоритмами смешивания микшера мультимедийных данных для повторной коммутации потоков мультимедийных данных сеанса. На этапе 800 к базовому(ым) алгоритму(ам) смешивания можно получить доступ с использованием протокола. На этапе 802 с использованием протокола задается передача коммутации участникам сеанса. На этапе 804 задается передача коммутации участникам сеанса с использованием протокола и согласно политике сеанса. На этапе 806 с использованием протокола лидером сеанса задается изменение в смеси участников сеанса конференцсвязи.

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

Согласно фиг.9 на ней изображена блок-схема вычислительной системы 900, функционирующей для исполнения коммутации потока мультимедийных данных на уровне базового алгоритма смешивания согласно раскрытой архитектуре протокола. Для обеспечения дополнительного контекста для различных аспектов, фиг.9 и нижеследующее обсуждение предназначены для обеспечения краткого общего описания соответствующей вычислительной системы 900, в которой могут быть реализованы эти различные аспекты. Несмотря на то, что вышеупомянутое описание находится в общем контексте исполнимых компьютером инструкций, которые могут выполняться на одном или нескольких компьютерах, специалистам в данной области техники будет понятно, что новый вариант осуществления также может быть реализован в комбинации с другими программными модулями и/или как комбинация аппаратного обеспечения и программного обеспечения.

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

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

Компьютер, как правило, включает в себя множество машиночитаемых носителей информации. Машиночитаемыми носителями информации могут быть любые доступные носители информации, к которым можно получить доступ посредством компьютера и которые включают в себя энергозависимые и энергонезависимые носители информации, съемные и несъемные носители информации. В качестве примера машиночитаемые носители информации могут включать в себя компьютерные носители информации, среды связи и т.д. Компьютерные носители информации включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители информации, реализованные любым способом или технологией для хранения информации, например, машиночитаемых инструкций, структур данных, программных модулей или других данных. Компьютерные носители информации включают в себя, например, RAM, ROM, EEPROM, флеш-память или другую технологию памяти, CD-ROM, цифровой видеодиск (DVD) или другой накопитель на оптических дисках, магнитофонные кассеты, магнитную ленту, накопитель на магнитных дисках или другие магнитные запоминающие устройства или любой другой носитель информации, который можно использовать для хранения требуемой информации и к которому можно получить доступ посредством компьютера.

Согласно фиг.9 иллюстративная вычислительная система 900 для реализации различных аспектов включает в себя компьютер 902, содержащий процессор 904, системную память 906 и системную шину 908. Системная шина 908 обеспечивает интерфейс для системных компонентов, включающих в себя, например, системную память 906 для процессора 904. Процессор 904 может быть любым из различных серийно выпускаемых процессоров. Сдвоенные микропроцессоры и другие многопроцессорные архитектуры также могут использоваться в качестве процессора 904.

Системная шина 908 может быть шинной структурой любого из нескольких типов, которая также может соединяться с шиной памяти (посредством контроллера памяти или без него), шиной периферийных устройств и локальной шиной с использованием любой из множества серийно выпускаемых шинных архитектур. Системная память 906 может включать в себя энергонезависимую память (NON-VOL) 910 и/или энергозависимую память 912 (например, оперативное запоминающее устройство (RAM)). Базовая система ввода-вывода (BIOS) может храниться в энергонезависимой памяти 910 (например, ROM, EPROM, EEPROM и т.д.), причем BIOS является стандартными программами, которые способствуют передаче информации между элементами внутри компьютера 902, например, во время запуска. Энергозависимая память 912 может также включать в себя высокоскоростное RAM, например, статическое RAM для кэширования данных.

Компьютер 902 также включает в себя внутренний накопитель на жестких дисках (HDD) 914 (например, EIDE, SATA), внутренний HDD 914 которого может также быть выполнен с возможностью внешнего использования в подходящем корпусе, накопитель на гибких магнитных дисках (FDD) 916 (например, для считывания со съемной дискеты 918 или записи на нее) и накопитель 920 на оптических дисках (например, считывающий диск 922 CD-ROM или для считывания с других оптических носителей информации большой емкости, например, DVD, или записи на них). HDD 914, FDD 916 и накопитель 920 на оптических дисках могут быть соединены с системной шиной 908 интерфейсом 924 HDD, интерфейсом 926 FDD и интерфейсом 928 накопителя на оптических дисках, соответственно. Интерфейс 924 HDD для реализаций внешнего накопителя может включать в себя, по меньшей мере, одну или обе из технологий интерфейса IEEE 1394 и универсальной последовательной шины (USB).

Накопители и относящиеся к ним машиночитаемые носители информации обеспечивают энергонезависимое запоминающее устройство данных, структур данных, исполнимых компьютером инструкций и т.д. Для компьютера 902 накопители и носители информации обеспечивают хранение любых данных в соответствующем цифровом формате. Хотя приведенное выше описание машиночитаемых носителей информации относится к HDD, съемной магнитной дискете (например, FDD) и съемным оптическим носителям информации, например CD или DVD, специалистам в данной области техники должно быть понятно, что другие типы носителей информации, с которых может считывать компьютер, например zip-накопители, магнитофонные кассеты, платы флэш-памяти, кассеты и т.п., могут также использоваться в иллюстративной рабочей среде, и также, что любые такие носители информации могут содержать исполнимые компьютером инструкции для выполнения новых способов раскрытой архитектуры.

Несколько программных модулей могут храниться в накопителях и энергозависимой памяти 912, в том числе операционная система 930, одна или несколько прикладных программ 932, другие программные модули 934 и данные 936 программ. Одна или несколько прикладных программ 932, другие программные модули 934 и данные 936 программ могут включать в себя алгоритмы 102 смешивания, микшер 104 мультимедийных данных, входные потоки 106 мультимедийных данных, режима 108 смешивания, интерфейс 110 протокола, инструкции 112 протокола, выходные потоки 114 мультимедийных данных, алгоритм 310 смешивания аудиоданных, алгоритм 320 смешивания видеоданных, входные потоки 400 мультимедийных данных, выходные потоки 402 мультимедийных данных и схему 500, например.

Операционная система, приложения, модули и/или данные могут также кэшироваться целиком или частями в энергозависимой памяти 912. Должно быть понятно, что раскрытая архитектура может быть реализована с различными серийно выпускаемыми операционными системами или комбинациями операционных систем.

Пользователь может вводить команды и информацию в компьютер 902 посредством одного или нескольких проводных/беспроводных устройств ввода, например клавиатуры 938 и указательного устройства, например мыши 940. Другие устройства ввода (не изображены) могут включать в себя микрофон, инфракрасный пульт дистанционного управления, джойстик, игровой планшет, перо, сенсорный экран и т.п. Эти и другие устройства ввода часто соединены с процессором 904 через интерфейс 942 устройства ввода, который соединен с системной шиной 908, но могут быть соединены посредством других интерфейсов, например параллельного порта, последовательного порта IEEE 1394, игрового порта, порта USB, инфракрасного интерфейса и т.д.

Монитор 944 или дисплей другого типа также соединен с системной шиной 908 через интерфейс, например видеоадаптер 946. Наряду с монитором 944, компьютер, как правило, содержит другие периферийные устройства вывода (не изображены), например динамики, принтеры и т.д.

Компьютер 902 может функционировать в сетевой среде с использованием логических соединений посредством проводной и/или беспроводной связи с одним или несколькими удаленными компьютерами, например, удаленным(и) компьютером(ами) 948. Удаленный(ые) компьютер(ы) 948 может (могут) быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, портативным компьютером, развлекательным оборудованием на осно