Si puede controlar el servidor, pídale que envíe los datos a la tasa promedio correcta a largo plazo. Entonces, el PIC solo necesita lidiar con la explosión. Con un búfer lo suficientemente grande, todo debería funcionar.
Inevitablemente, los dos relojes estarán un poco apagados. El promedio a largo plazo de cada uno debe ser tan bueno como su cristal. Para ser pesimista, figura 50 ppm de cristales en ambos extremos, así que diseña hasta 100 ppm de desajuste a largo plazo. Esto puede ser tratado de varias maneras. Simplemente podría replicar la última muestra en el buffer underrun y omitir una muestra en la saturación, ya que en teoría cada evento será relativamente raro. O bien, puede cambiar ligeramente la velocidad de reproducción según la cantidad de datos en el búfer. A los usuarios de audio no les va a gustar eso, pero no es diferente a las oscilaciones de las grabadoras desde hace mucho tiempo. Por debajo de algún nivel es todo lo suficientemente bueno. Si este sonido es de voz, puedes salirte con mucho más que si un músico profesional está escuchando música.
En cualquier caso, no, no quieres usar TCP. Eso agregará tanta sobrecarga en el extremo PIC que es posible que no pueda manejar la transmisión de audio. No hay necesidad de entrega confiable aquí. Si hay un error, el error de salida, pero luego desea continuar y continuar normalmente lo más rápido posible. TCP no es adecuado para eso.