помогите звук оцифровать

[Alexeyslav]

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

[mrFox]

А если передавать на один отсчет больше чем воспроизводится?

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

[sabir]

вообщим на ebay нашёл шото пахожее..

NRF24L01 2.4G wireless digital audio transceiver module sound speaker adapter 5V
http://www.ebay.com/itm/NRF24L01-2-4G-w ... 43bc72f94d

вот интересно самому такое сфарганить...

[Alexeyslav]

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

[mrFox]

...буфер приемный растет, задержка вывода растет...

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

...NRF24L01 2.4G wireless digital audio transceiver module sound speaker adapter 5V...

радиомодуль для подобного я уже предлагал - RFM73
к нему МК и запрограммировать - будет тоже самое

[Alexeyslav]

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

Кварцы сомнительного качества дадут всего 4 порядка стабильности частоты при современных частотах семплирования получим разницу в частотах заметной на семплах в 1-2 секунды. А если попадутся китайские "кварцы" так у них разброс может быть до 2%, попались мне однажды такие в USB-хабе на 10 дырок.

[mrFox]

Выкидывать отсчеты и добавлять левые - дурной тон.

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

Под частоту надо подстраиваться плавно.

а не будет, что 1 секунду лишний отсчет, другую на отсчет меньше
и будет постоянное переключение частоты
управлять стоит частотой отправки - передатчик подстраивает свою частоту передачи под приемник

[Alexeyslav]

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

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

[mrFox]

Источник звука может быть очень сложным, надо будет научить все источники звука управлять собственной частотой?

истосник звука - он всегда один - твоя-же платка с АЦП, МК и передатчиком

..она ведь будет меняться плавно...

ну это не всегда возможно

В общем почему бы не сделать интерполяцию - из 5 последних делаем 4 / из 4 делаем 5

[Alexeyslav]

Да, но прежде чем добавить/убрать один отсчет нужно ведь как-то узнать что он лишний...

[mrFox]

что мешает 1 раз в секунду определять, сколько данных прошло и сколько в буфере

[sabir]

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

[mrFox]

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

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

[Alexeyslav]

А как ты определишь что пришло их больше или меньше? Ведь задача - устройства вывести все что пришло.
Просто со временем разница между пришедшим и выведенным будет расти увеличивая размер необходимого буфера. На его размер и надо ориентироваться - стабилизировать на определённой величине путем управления скоростью вывода чтобы с одной стороны иметь запас до переполнения а с другой не допустить остановки ЦАП при опустошении буфера если пакет данных не вовремя придёт(с радиоканалом такое часто бывает).

[sabir]

А как ты определишь что пришло их больше или меньше? Ведь задача - устройства вывести все что пришло. Просто со временем разница...

в конце каждого пакета ставить синхроимпульсы,(конец пакета) и пусть ЦАП преобразует "то что есть"..

[Alexeyslav]

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

[balmer]

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

Верный подход. Хотя в реальности достаточно такого:
- буфер переполнился? Пропускаем часть данных, пока буфер не стал наполовину полным.
- буфер опустошился? Останавливаем воспроизведение, пока буфер не заполнился наполовину.

Даже если кварцы расходятся на 1 секунду в час, это мало кто заметит.

[Alexeyslav]

Половина буфера это может быть довольно много. Помимо расхождения, пока сработает ваш алгоритм "сброса" будет меняться задержка в каналах, это чревато искажениями звука особенно когда больше 2-х каналов. Во вторых, это просто непрофессионально. Если уж так сильно пофиг на звук, то проще его передавать классическим способом - при помощи банальной ЧМ модуляции, в аналоговом виде - никаких проблем не будет.
Один лишь факт того что звук необходимо передать в цифровом виде говорит о том что на качество звука не пофиг, и будет очень грубо вырезать из звука отсчеты или вставлять паузу хоть и раз в час. Кстати, обычный кварц дает точность 10^-5 в лучшем случае без термостатирования - 2...3 секунды звука и уже будет разница на один отсчет.

Да и необходимо все очень хорошо подумать и взвесить прежде чем строить передачу звука по схеме АЦП-линия_цифровой_передачи-ЦАП т.к. на АЦП потеряем в качестве, и ЦАП добавит искажений, а если брать выход с компьютера - так накладывается еще одно преобразование цифра-аналог и добавляются шумы. В результате выход на приемнике будет иметь неудовлетворительные характеристики, и разницы в передаче по сравнению с аналоговым каналом просто не будет.

[balmer]

Половина буфера это может быть довольно много.

Обычно ставлю буфер порядка 0.2-0.5 сек, в зависимости от задачи.

Кстати, обычный кварц дает точность 10^-5 в лучшем случае без термостатирования - 2...3 секунды звука и уже будет разница на один отсчет.

Человек не услышит задержку звука на один отсчет.
Впрочем тут важна не точность кварца, а возможная разница во времени хода кварца между приемником и передатчиком.
Это все таки ближе к 1e-4.

[Alexeyslav]

Не услышит, если сразу же принимать меры и корректировать скорость. А если просто допускать переполнения буфера и тогда предпринимать что-то, то этот процесс будет неприятным.

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