Доброго времени суток, уважаемые!
Такой вопрос, при снятии звука с микрофона, его по сути можно запихнуть в буфер либо в 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, думаю он поможет решить проблему параллельной передачи данных.
и насчет личного и рабочего..оно уже личное) половина готова решения, осталось чуть чуть, и заработает)) ну и конечно же я не рву на себе волосы и не бросаю остальную работу, более серьезных задач нет, по мелочи только софт кое-где подправляю, поэтому все нормально)

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

ну так вот как раз величинами в этом массиве все и задается(высота, тембр и т.п). от громкости и высоты длина массива данных не зависит, хоть ты молчать будешь(нули будут) или орать (ближе к 255 на каждый байт)..но идея плоха тем, что в реальном времени это почти нереально сделать, самая главная задача, это снизить задержки на передачу данных из точки А в точку Б, и поэтому вариант с сервером-маршрутизатором мне тоже не нравится..