Constrain ALSA buffer size and start_threshold in fallback path

[honza]

When buffer/period negotiation fails and we fall back to the device's defaults, some devices (e.g. USB audio via the front: plugin) end up with enormous buffers (1M+ frames at 44.1 kHz = ~23 seconds of audio).

This causes two user-visible problems:

1. Playback start is delayed because start_threshold is set to buffer_size - period_size, so ALSA waits for ~23 seconds of data to be written before producing any output.

2. Track changes block because drain() must wait for the entire buffer to play out before the sink can be reopened for the next track.

Fix both by:

• Calling set_buffer_size_near(MAX_BUFFER) on the fallback hw params so the device picks a buffer close to 500 ms instead of its unconstrained default. This is best-effort (errors are ignored) and does not change behavior for devices that already negotiate successfully.

• Capping start_threshold to at most SAMPLE_RATE frames (1 second) so that even if the buffer is still large, playback begins promptly.

[photovoltex]

sounds reasonable to me. what do you think about the changes @roderickvd?

[roderickvd]

The issue with pathologically large device defaults is real. Capping is a smart thing to do. 500 ms is still quite large, I'd go for 100 ms. There's an ALSA API to set this in terms of duration instead of frames, which could be easier, as you wish.

Take care with the start threshold: if it's larger than the buffer could fill up, then there's a chance that playback would never start. Ideally it's at least twice the device's period size, for double buffering.