Форум: "Система";
Текущий архив: 2002.02.18;
Скачать: [xml.tar.bz2];
ВнизЛогическая задачка (не могу справиться) Найти похожие ветки
← →
Exception (2001-11-14 09:58) [10]К сожалению, я не прочитал то, что написал, до того, как отправил.
Еще раз, и более подробно:
Использовать или не использовать DCOM - cовершенно не принципиально в этой ситуации (на самом деле даже нежелательно). Вопрос стоит не в том, через что передавать данные, а как обеспечить работу приемника без задержек и при этом передеветь максимум аудиоданных при существенно ограниченной пропускной способности канала.
Одно из решений, на мой взгляд, таково:
Сервер делает следующее:
- оцыфровывает аудиоданные порциями, скажем, по 0.1 сек.
- сжимет порции
- накапливает сжатые порции в буфере (скажем на 10-100 порций - т.е. 1-10 сек.) - это необходимо, если возникнет задержка, вызванная ограниченной проп. способностью канала.
- паралельно с этим непрерывным потоком посылает сжатые порции из буфера, если они там есть, конечно. Если это принципиально, то он может начинать посылку пакета порций (т.е. столько порций, сколько необходимо набрать до некоторой суммарной длины - она определяется по интервалу между посылками и проп. способности канала) через равные интервалы времени.
Клиент:
- получает данные от сервера
- каждую 1/10 секунды воспроизводит очередной пакет.
Результат: задержка востроизведения мажду клиентом и сервером - 1/10 секунды, либо больше - если наступит такой момент, когда не хватит пропускной способности канала. Для решения этой проблемы достаточно (если передаем именно разговор) иногда пропускать "тишину" - т.е. не востроизводить пакеты "с молчанием" на клиенте. Вернее, сервер вообще должен их пропускать при посылке, если в данный момент клиент "не успевает". Кроме того, можно изменить значение "0.1 сек." - чем больше, тем больше степень сжатия, естественно, но и задержка - тоже.
Вроде-бы все.
Страницы: 1 вся ветка
Форум: "Система";
Текущий архив: 2002.02.18;
Скачать: [xml.tar.bz2];
Память: 0.45 MB
Время: 0.004 c