Pull to refresh

Comments 26

В классе ReceiverPlayer у поля finishFlag забыли поставить volatile.
Спасибо, как-то недоглядел.
Уточните пожалуйста, вы использовали голый PCM без компрессии/синхронизации?
А почему вы проигнорировали сжатие и специализированные медиа-протоколы вроде RTP?
Просто хотелось поэкспериментировать, попробовать реализовать все это на более-менее низком уровне.
К примеру, для голосовой связи вполне подходит
sampleRate = 8000, sampleSizeInBits = 8, channels = 1.
Итого — всего 64 kbs.

Для трансляции музыки в домашней сети можно установить качество получше. Даже без сжатия — скорость вполне позволяет.

О сжатии и специализированных протоколах стоит задуматься, если искать более серьезное применение.
Если эта домашняя сеть проложена как минимум Ethernet. При удовлетворительном качестве CD-DA имеем 44100*16*2 — примерно полтора мегабита. Вайфай, да через пару капитальных стен, такое не протянет.
У меня стоит вай-фай роутер и точка доступа в качестве повторителя (как раз из-за капитальных стен в 3к-квартире ее поставил).
На 16000*16*2 (0.5 мегабит) тянет вполне.
И качество звука приличное.
Вообще стандарт 802.11n предусматривает 150 Мбит/с при одной антенне.
эти 150 мегабит даны для идеальных условий — ровно два устройства без препятствий и помех. Как только в эксперименте появляются капитальные стены, репитеры, микроволновки и соседи со своими точками, настроенными кучно именно на ваш канал, вся прелесть от громкого показателя улетучивается.
WiFi сеть единого информационного пространства, и если поставить вторую пару девайсов, скорость начнет делиться между ними. А когда дом многоквартирный и видно порядка 20-30 точек и при этом ни одного свободного канала. Учитывая еще факт, что 5ГГц у нас как бы и не разрешен, а в 2.4ГГц желающие тупо влезть и не могут. Так в таких условиях на 802.11n скорость проседает по самое нихочу. А когда еще половина точек сидит на 802.11bg и покрывают все доступные каналы, то вашим 802.11n можно и в туалете подтереться, все 802.11n точки будут работать в режиме 802.11bg и не более. Ну и да, забыл еще момент, если даже у всех точки 802.11n, но используют устройства 802.11bg, то работать будет именно в режиме 802.11bg. И ни у кого на данном канале не будет 802.11n, вообще.
5 ГГц в России разрешены примерно на тех же условиях, что и 2.4: в закрытых помещениях — без дополнительных разрешений: Решение ГКРЧ от 20 декабря 2011 г. № 11-13-07-1 «О внесении изменений в решение ГКРЧ от 7 мая 2007 г. № 07-20-03-001 «О выделении полос радиочастот устройствам малого радиуса действия»
Ну судя по этому же документу, допускается видимо только в случае, если стены заэкранировать, а так под сноску можно приписать всё что угодно (смотрим 4й пунктик):

>> Условие применения устройств малого радиуса действия внутри закрытых помещений предусматривает
>> дополнительное ослабление радиосигнала от указанных устройств в направлении других РЭС,
>> функционирующих в соответствии с Таблицей распределения полос частот между радиослужбами
>> Российской Федерации, вносимое конструкциями помещений

4й смотрим потому что точки обычно имеют мощность 100мВт, но ширина канала WiFi 20 или 40МГц, получаем, что вылезает за рамки 2мВт/МГц и 2й пунктик уже не подходит, да и во 2м указан только 2.4ГГц. Так что дяди могут придти, посмотреть и сказать, а чего у вас стеночки-то не заэкранированы, нехорошл получается, нарушаемс.
Попробовал замерить реальную скорость вай-фая между двумя самыми удаленными комнатами с помощью wget.
Примерно 1.8 МБайт/c — или 14.4 Мбит.
Вот, реальный показатель в 10 меньше маркетингового. Еще одна неприятность — пинг около пары миллисекунд, то есть если синхронно транслировать в двух комнатах, будет противный эффект эхо.
Почему так, описал выше. Проводил опыт в идеальных условиях, да, всё нормально, скорости заявленные. Но если есть влияние на канал устаревшего оборудования, начинаются проблемы.
вполне годно для начала написания корпоративной скайпо-подобной системы
По идее можно сделать сервер, который будет хранить текущие айпишники каждого абонента.
Клиент получает с сервера нужный айпишник, и делает прямой звонок.
Ну и шифрование данных можно сделать какое-нибудь.
Простейший вариант, который приходит на ум — обычное XOR-шифрование.
Если зашифрованный XOR'ом текст можно подвергнуть статистическому анализу — сделать то же самое для потока байтов, кодирующих звук, по-моему, на порядок сложнее (с первого взгляда вообще невозможно).
Допустим, при каждом создании канала генерируется случайный ключ определенного размера и передается второму абоненту методом двойного рукопожатия. Получается дешево и сердито.
(Закадровым голосом из Цивилизации):
Вы изобрели протоколы SRTP и SIP.

В потоке байтов, кодирующих звук, будет преобладать 0, 0 XOR A = A: пока собеседник молчит, будет передаваться сам ключ, увы.

В качестве корпоративной системы стоит взять таки Asterisk в роли сервера и Linphone в роли клиента (есть на все полатформы). На Андроид также есть CSipSimple с огромным количеством настроек.
Точно. Тишину я как-то не учел ))
Если уж брать готовые системы, то для того же XMPP(Jabber) существуют клиенты с возможностью прямой голосовой связи.
В плане настройки по-моему XMPP-сервер на порядок проще, чем Asterisk.
Если речь идет о «просто поговорить», то нужно поправить (мануалы есть в огромных количествах) два файла — sip.conf и extensions.conf
(Ну как поправить… списать дуб из мануала и готово)

Найти не закрытого клиента на андроид, который в состоянии позвонить клиенту на десктопе по Jabber/Jinge мне пока не удалось.
Очень странная (и не используемая) переменная в п.1
Scanner sc = new Scanner(System.in);
Изначально вместо while(true) стояло while (!sc.next().equals(«quit»)).
Просто переменную не удалил.
Спасибо за замечание, сейчас исправлю.
А исходники можно куда-нибудь перезалить? Ссылка на Гите протухла…

Исправил ссылку.

Sign up to leave a comment.

Articles