Set connection, listener, bandwidth and buffer limits to suit your server. These settings serve different purposes; clients does not control every limit. Start by identifying which resource is running short.
Distinguish the limits
| Setting | Operational meaning |
|---|---|
limits/clients | Broad concurrent-client protection, including non-listener activity |
limits/max-listeners | Server-wide listener cap |
mount/max-listeners | Listener cap for a selected mount policy |
max-bandwidth | Bandwidth control at its configured global or mount scope |
queue-size | Upper queue boundary for listener lag |
min-queue-size | Minimum retained queue setting supported by the pinned parser |
burst-size | Initial media offered to a connecting player |
source-timeout | Time permitted without incoming source data |
Certain authenticated relay connections have special treatment in KH’s admission model. A test of ordinary listeners alone does not establish how a relay affects limits. Leave capacity for administration and other non-listening HTTP work.
Understand byte and time-based sizing
KH documentation allows time-based sizing for certain queue/burst values, for example 4s. That is KH behaviour with conversion tied to media rate, not a portable XML convention for every Icecast variant. Start with explicit byte values if the rate interpretation has not been verified for your media.
This fragment replaces values in an existing mount block:
<queue-size>524288</queue-size>
<burst-size>65536</burst-size>
<max-listeners>20</max-listeners>These are test values. Keep the initial burst consistent with the queue budget, and remember the player’s own buffer adds latency. More buffer cannot repair a continuously undersupplied network. Large queues can let a listener fall further behind rather than improve the live experience.
Measure the actual bottleneck
Record active sources, concurrent listeners, outgoing media rate, slow-client evidence and available memory/network capacity. Change one control and reproduce the same source/player test. Exercise listener overflow and authenticated relay behaviour separately. Do not present a theoretical bitrate calculation as a benchmark or assert that a KH option makes one build faster than another without comparable measurements.