Доброго времени суток, уважаемые!
Такой вопрос, при снятии звука с микрофона, его по сути можно запихнуть в буфер либо в MemoryStream.
Как запихать туда конечно тоже не совсем понятно(directX втупляю, научился пока писать в wav используя NAudio либу)

а как потом передавать по сети это богатсво? возможно ли писать в один stream, и его же тут же передавать по сети..т.е. как бы перенаправлять на сокет, аля линукс, там вывод с любого устройства можно куда угодно перенаправить.

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

Добавлено через 1 минуту и 4 секунды
раз ты можешь его записать в файл, и если ты любой файл можешь передать по сети(в виде потока байтов) то очевидно что ты можешь те данные которые ты записываешь в файл отправить туда куда тебе нужно...

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

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

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

т.е.


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

Не вижу смысла делать буферизацию как таковую. Есть ощущение, что даже если ты сразу будешь слать в сеть, то что приходит в событии, то тоже все нормально будет. Так как сам протокол IP все равно отправляет очень маленькими кусочками по 50-100 байт... Правда эксперименты лучше проводить между компами в локальной сети или даже вообще на одном компе, чтоб исключить в этот момент влияние задержек.
Буфер может тут понадобиться, только как конвейер между записывающей частью и отправляющей в сеть. То есть в одном потоке в него пишется, а вторым потоком непрерывно читается и отправляется в сеть. Это нужно чтобы исключить потерю данных в случае медленной отправки. Хотя, на практике, предпочитают терять входные данные в противовес накоплению.

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

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

Это сообщение отредактировал(а) puZzo - 18.2.2011, 05:56

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

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

Я так понимаю, все это в образовательных целях? Потому как в Директ-икс, насколько я знаю, уже все это есть, включая сжатие, поддержку различных протоколов, передача по сети и прочее.

как раз таки не в образовательных) на работе нужно заменить старые селекторные установки..DirectSound ковырял, но чет сложно там както, да и информации скудновато..

Потому как в Директ-икс, насколько я знаю, уже все это есть, включая сжатие, поддержку различных протоколов, передача по сети и прочее. 

можно поподробнее? где почитать про это можно?

Это сообщение отредактировал(а) puZzo - 18.2.2011, 07:09

Не могу сказать точно, так как готовых ссылок в избранном нет. И сам не работал с директ-иксом в этом направлении. Просто где-то как-то то ли слышал, то ли демки качал, где это было сделано. Помоему, в стандарном Managed DirectX SDK есть пример, если не ошибаюсь. Поищи хорошо, надеюсь, что я все правильно когда-то услышал или понял.

вчера на работе завязался у меня спор с коллегами, они предлагали сделать на сервере микшер, который бы сливал из N потоков данных в один и отправлял бы обратно. Я им пытался объяснить что на сервере слишком мала вероятность одновременного прихода двух пакетов с данными, чтобы их сливать, в итоге они будут отправляться по одиночке, и все равно у клиентов получится очередь. 

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

какие мысли по этому поводу будут?

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

puZzo, а как предлагалось "микшировать"? т.е. как сложить вместе два куска звука длиной скажем по 0,5 сек?

-Mikle- вот и я про тоже! сделал тестовую приложуху, передавал просто байт, и сервером проверял, если есть результаты(хотя бы у одного потока) то слаживал..в итоге вообщем получилось 50х50 т.н. микширования(в данном случае плюсования) + потеря "пакетов" ~40-50%, т.к. в то время пока я там проверял, сливал и. пр фигней занимался в нескольких потоках уже спели данные обновиться. пытался делать задержку в потоках, до тех пор пока не считаются оттуда данные, но все равно фигня получается.

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

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


но это всего лишь мое (некомпетентное) видение вопроса, думаю не все так просто.

Это сообщение отредактировал(а) puZzo - 20.2.2011, 14:17

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

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