Необходимо сделать такое устроство. На одной стороне стоит контроллер LPC1766, ADC которого цифрует 10 бит данных при 100 кГц тактовой частоте, дальше этот процессор должен отфильтровать данные FIR-ом и послать буфер 1024 байта в Ethernet, второй процессор принимает эти данные и пропускает через ЦАП. Проблема этой задачи такова:

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

Конечно, народ и решает и стандартизирует, только сложность решения ни в какое сравнение с пукалкой на LPC1766 не идет. Да и для выхода на рабочий режим с "пропуски пакетов категорически запрещены" будет требоваться время, да то категорично так не выйдет - как часто slip допустимы? Минута, это одно, час другое, месяц - третье, никогда - это фантастика.
http://www.lastmile.su/issue/2009/4/4
Если Ethernet это чистая физика точка-точка, то тогда можно пробовать делать какую-нибудь синхронизацию прямо из Ethernet потока.

Т.к. частота дискретизации устройства 100 кГц и 10 бит разрядность, т.е. получается 16 бит * 100 кГц = 1,6 Mbps, при Fast ethernet (100Mbps) эта задача теоретически реализуема. При уточнении тз, оказывается допустимым задержка на 2..3 буфера по 1024 байта. (p.s. не совсем понял что имелось в виду под словом slip).

1. В предложенной вами ссылке рассматриваются протоколы синхронизации часов. Я так понимаю этим можно воспользоваться для синхронизации тактовых сигналов ацп и цап (реализовывать протокол в полном виде в этой задаче будет бессмысленно), т.е., скажем, делаем счетчик отсчетов на обеих сторонах, и если, допустим, на цапе счетчик отличается, то мы пересчитываем предделитель тактовой частоты, чтобы скомпенсировать уход. Устройство, с которого предлагается цифровать сигнал - спец. микрофон, на другой стороне - громкоговоритель + возможно, осциллограф.

2. Есть предложение способа синхронизации потока из изернета: на стороне цапа есть большой кольцевой буфер, скажем на 100 буферов, и две возможные частоты дискретизации цапа, одна больше чем у ацп, а другая меньше. Синхронизация происходит следующим образом. Буфер накаплвивает, скажем, половину пакетов и запускается таймер, по прерыванию которого подсчитывается количество буферов и на основе этого делается установка первой или второй частоты дискретизации цапа. Если буфер начинает переполняться, т.е. пакетов становится больше чем половина буфера, значит цапу устанавливается бОльшая частота дискретизации, если буферу не хватает пакетов, то цапу ставим меньшую чд. Таким образом частота дискретизации цапа качается постоянно туда/сюда (искажения и прочее конечно будут). Минус этой системы: чем больше буферов - тем лучше, можно поставить чд1 и чд2 близкие к ацп. Но ресурсы памяти у MCU ограничены.

Собственно вот пока пришли в голову две идеи. Если что понял не так или есть что лучше - поправьте.

Нет. NGN сетей.

Делал. Правда микрофон у меня не спец и терять пакеты можно.
ЦАП работает с частотой дискретизации чуть выше требуемой (точнее ближайшей возможной выше требуемой).
Заполняет некоторый буфер. Компандируется, вычисляется энергия, максимумы и проч. Буфер расщепляется на два: один содержит все четные отсчеты, второй - все нечетные. Буфера маркируются инкрементным счетчиком и по UDP отсылаются.

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

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

Интересное решение. Что будет, если пропадут сразу, скажем, 3 пакета. Замещаете уже существующими?

Если нет ни одного пакета из пары, то заменяю существующим с уменьшенным уровнем

Восстанавливали пропуски параллельной посылкой на другой UDP порт с задержкой.