Audio Broadcast Configuration - expose recorder time limit as user preference

[DSheirer]

Streaming recording time limit is currently set at a fixed 30 seconds. Expose as a user setting to allow a range of 30 - 120 seconds.

[davidmckenzie]

Thanks for this! The only reason I noticed it is because we had a pretty insane day yesterday with constant traffic. I wasn't monitoring the stream, only local audio, so not sure whether this caused any missed calls.

I did notice that it was throwing this error when the traffic was back and forth between multiple users. What conditions are involved in this? Is there a 'wait x seconds' thing before it initiates a new recording? If the recording times out does it need to wait for a break in traffic before it starts again, or does it immediately start the next "chunk"? Or is it just based on the channel creation/teardown logic?

I did get a few complaints from users that the delays were annoying, so can definitely see why you'd want to keep the time limit low. :)

[DSheirer]

The stream manager checks each recorder to see if has exceeded max time length. Once detected, the recording is closed out. The instant the next audio packet from that channel comes in, a new recording is started. As each recording is closed out, it is handed to the streaming queue where recordings are streamed out based on recording start time order. So, if you have a continuous call, it will be chopped every 30 seconds, which would likely induce a small (audible) break in streaming.

You can keep an eye on the streaming tab for the queue size. As the queue size grows, the delays will be longer.

I have figure out a strategy to handle when the streaming queue size grows too large -- should I automatically delete queued recordings in order to catch-up? Should audio priority figure into the strategy, etc.

[DSheirer]

Moving this to Build 0.4.0

Blocked on #51 since we can expose this system-wide property as a preference in the new preferences panel.

[ImagoTrigger]

I know this is old and I've repeated this before...but you say "I have figure out a strategy to handle when the streaming queue size grows too large" I suggest to stream two calls at once, one on each side (left/right) until the queue goes back down.