Cómo entender el tamaño correcto del búfer en el desarrollo

Agregue en los detalles de la pregunta el contexto en el que está preguntando: comunicación en tiempo real, recopilación de datos, base de datos, transmisión de medios, interfaz de almacenamiento masivo … Esos son casos muy diferentes.

Agregado después de que el OP aclaró:

Ajá.

Para la transmisión, tenga en cuenta el rendimiento de la red, la latencia y la estabilidad de la latencia (es decir, ¿hay ocasionales ‘hipo’ más largos causados, por ejemplo, por un canal compartido en algún lugar aguas arriba). Creo que es mejor adoptar un enfoque adaptativo: comience con unos segundos de datos, monitoree el búfer y extiéndalo (digamos, el doble) cada vez que alcance una marca de límite superior. No exagere: logrará muy poco si el tamaño de su búfer provoca el cambio de página (suponiendo que esté en un sistema operativo con paginación, por supuesto). Proporcione alguna forma de manejar el búfer agotado con gracia, tal vez incluso ofrezca al usuario cambiar a una versión de contenido de menor velocidad de bits.

Para la decodificación y el filtrado (en lugar de escuchar), el tamaño del búfer de recepción es menos importante, pero los algoritmos que está utilizando determinarán el tamaño del búfer de procesamiento. Supongo que la mayoría de los filtros son algoritmos de una pasada que funcionan con tramos de contenido relativamente cortos, por lo que eso no debería ser un problema.

Sugiero que para esto último estudies el código del codificador Lame (LAME MP3 Encoder :: Inside): estos tipos parecen saber lo que están haciendo. (Lame es codificador, no decodificador, y funciona fuera de línea, pero se enfrentaron a algunos de los mismos desafíos de administración de búfer que usted hace de todos modos).