Суть проблемы вы сталкиваетесь в том, что у вас есть АЦП и ЦАП на отдельных системах с различными локальными генераторами. Предположительно, вы планируете синхронизировать свои пакеты с 3-м (и, возможно, 4-м) процессором.
Правильное решение этой проблемы - это своего рода алгоритм clock recovery. Чтобы сделать это правильно, вам понадобятся некоторые средства точной маркировки (например, бит точности) переданных пакетов, а затем используйте PLL для управления тактовой частотой часов выборки приемника. Это именно тот подход, который используют как IEEE1394 аудио, так и MPEG2 Транспортные потоки.
Так как, возможно, вы не можете сделать ни одну из этих вещей, ваш подход, скорее всего, будет включать периодическое удаление или повторение выборок (или даже целых пакетов), чтобы ваш буфер приема находился под или чрезмерно.
У USB Audio аналогичная нехватка аппаратной поддержки для восстановления часов, и используемые там подходы могут быть применимы к вашей ситуации.
Опираясь на сроки передачи и приема сетевых пакетов, это ужасная идея. Дрожание во время доставки является ужасным - особенно с Wi-Fi или сотовой связью. Вам было бы полезно использовать не полагаться на него вообще, а вместо этого выполнять как аудио IEEE1394, так и MPEG 2 TS, что должно отделить передачу аудиоданных от потребления с использованием модели FIFO, в которой данные потребляются с постоянной скоростью и доставлены ему в пакеты ненадежного времени.
Что касается ALSA, то все, что он может сделать (если только не имеет точной внешней привязки по времени), является измерение дрейфа между отсчетными часами аудиоинтерфейса и часами ЦП. Это не дает «точной частоты» чего-либо, поскольку ни один из осцилляторов не может быть точным, и оба могут дрейфовать в зависимости от температуры.