LINUX.ORG.RU
ФорумTalks

софтовая рация (PTT) по IP - существует ли?

 ptt, , , ,


1

2

Собственно хочется узнать - есть ли в природе софт для PTT over IP? А то жабберы хорошо, но как бы 21 век на дворе, а трёп по телефону - зло.

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

Разумеется никакого гуя, и прочего, посему всякие аддоны к жабберам не катят вообще. Надо чтобы вообще ничего кроме PTT в софтине не было.

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

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

Я это к чему - есть у меня тупенький самописный клиент-сервер для этого ( oss/alsa, speex nb, tcp, даже клиент для Symbian есть ), однако, я при написании заморочился на минимальных задержках ( чтоб как в настоящей рации было - выпендрился, блин ) и протокол такой, что сервак начинает слать клиентам речь после первого же фрейма. На верёвке или через WiFi работает идеально, но через мать, его, 3G или того хуже, жопорез...

[гнев]тыща лучей поноса уродским тупорылым опсосам у которых голосовой трафик с какого-то хрена имеет приоритет над IP, хоть и должно быть строго наоборот, ибо юзеры IP платят в разы больше бабла чем всякие нищие голосовые абоненты, и вообще, сцуки, до сих пор оптикой не могут БСки затянуть хотя бы в центральных регионах[/гнев]

Полез ковыряться - блинский фиг, там надо почти всё доковыривать, чтобы режим для жопореза сделать. Ну типа чтобы если на сервер приехал флажок «говносвязь», сервер сначала буферизовал всю фразу (от нажатия до отпускания кнопки юзером) и только потом рассылал всем, ну и клиент соответственно - сначала всё принимал бы, а уже потом воспроизводил. Несложно, конечно, но лениво. :)

В общем, может нефиг мне изобретать лисапед, и уже давно есть грамотная открытая, маленькая и простая реализация PTT over IP чтоб без рюшечек и легко портируемое?

★★★★★
Ответ на: комментарий от Artificial_Thought

Увы, это не то что надо.

Mumble is an open source, low-latency, high quality voice chat software primarily intended for use while gaming.

А надо high-latency, low quality. Кроме того, оно UDP и требует чтобы QoS оборудованием обрабатывался как положено. Все без исключения опсосы клали болт на QoS и половину UDP пакетов потеряют.

Я пробовал его - 3G с трудом, жопорез - вообще никак. Ну и от гуя сходу не избавиться.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от dikiy

ты вообще понимаешь, что значит low latency?

Да, понимаю. И оно мне как раз нафиг не надо в таком варианте. Мне похрену сколько времени пройдёт между нажатием кнопки юзером и появлением звука у других юзеров. Главное чтобы то, что было сказано между нажатием и отпусканием кнопки юзером дошло до остальных целиком, без выпадений и 100%-но. Да пусть хоть несколько минут пакеты через долбаного опсоса просираются - наплевать совершенно.

Low-latency вариант у меня и так есть, в чём сосбственно и заключается проблема. Добавлять ли туда опсосоустойчивый high-latency режим или же велосипед уже изобретён я и хочу выяснить в данной теме.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от kostian

Тупо пару костылей + mailinglist?

Дописать high-latency в мою поделку несколько проще, чем придумывать костыли к десктопным и мобильным мыльницам. Ну и хочется всё-же что-то отдельное, маленькое. Да и от low-latency режима отказываться не хочется.

Хотя идея без сомнения зачётная и юниксвейная, я оценил. :)

Stanson ★★★★★
() автор топика
Ответ на: комментарий от dikiy

Денису лучше знать, не мешай ему.

Deleted
()
Ответ на: комментарий от Quasar

А как при этом и low-latency поиметь? Ну, для тех кто не через жопорез?

Stanson ★★★★★
() автор топика

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

rezedent12 ☆☆☆
()

мы в провайдере покупали какую-то дорогую штуку и потом её цепляли через транспорт в teamviewer

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от Stanson

high quality А надо low quality

http://visionary-pw.clan.su/_fr/1/0902669.png

В экспертных настройках moar.

Кроме того, оно UDP

В тех же экспертных настройках емнип есть режим TCP.

INFOMAN ★★★★★
()
Последнее исправление: INFOMAN (всего исправлений: 1)
Ответ на: комментарий от cache

Говорят в вайне работает. Нативного клиента нет. Можно еще поизвращаться и попробовать запустить в эмуляторе андройда.

Morphine
()
Ответ на: комментарий от rezedent12

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

Качество звука в mumble/murmur это лишь битрейт speex и никак не влияет на сам принцип передачи пакета который совершенно не учитывает возможность потерь и аццких задержек.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от INFOMAN

В экспертных настройках moar.

Низкая пропускная способность канала != Говённое качество канала. На 3G, например, пропускная способность высокая, а качество может быть вообще никаким.

В тех же экспертных настройках емнип есть режим TCP.

Возможно и есть, только это не поможет решить проблему с опсосами.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от rezedent12

Force TCP

И как это поможет побороть запор у опсоса? Да, с tcp пакеты доедут и не потеряются бесследно как могут потеряться udp, но tcp совсем не гарантирует доставку пакета за вменяемое время, что означает затыки и кваканье.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от rezedent12

Да я и сам с усам, и так уже написано частично, причём и для смартов тоже, просто велосипеды писать не очень люблю.

Но, видимо, это совсем не велосипед получается, если до сих никто мордой не ткнул в готовое, годное для дерьмовой связи решение PTT over IP.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Это реализовать то просто. Только надо буферизацию выставлять на несколько секунд. И через TCP естественно данные передавать. Если передаёшь именно голос, то можно применять специальные кодеки и сузить частотный диапазон.

rezedent12 ☆☆☆
()
Ответ на: комментарий от rezedent12

Всё проще - в клиенте всегда есть 2 события - нажатие кнопки и отпускание кнопки. Поэтому всегда заведомо известно, когда звуковой поток начался и когда закончился. У меня и так передаются флажки «начало звука» и «конец звука». Надо всего лишь добавить в протокол флажок «говносвязь» чтобы сервер не передавал дальше пакеты пока, наконец, не получит пакет с флагом «конец звука» от клиента. Приём на стороне клиента с говносвязью так же сделать - чтобы не воспроизводил пока всё не примет.

Что до кодека - Speex Narrow Band более чем годен для передачи речи. Не хуже AMR в общем-то. ( AMR пользовал т.к. в симбианофонах кодек AMR обычно хардверный, но отказался потом, в пользу speex )

Stanson ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.