Do your implementation need to set specific start threshold to prevent the driver automatically start when you fill the buffer ?
Do the driver allow to start when there is no data ?
It's the responsibility of the client to set the start threshold to a safe and responsible value.
It might suit some applications to allow both threshold start _and_ start_at: My implementation doesn't preclude this.
Now I am confused... My understanding was that this feature is similar to SSYNC in HDAudio, where everything is ready, buffers filled, DMAs armed, FIFOs filled and the start condition only opens the last gate at a specific time - possibly with multiple streams starting at the same time. If you add a condition on the start_threshold you really don't need any hardware-driven start, do you?
What you've described is exactly what I had in mind, so we're still on
the same page.
I wanted to make it clear that my implementation of start_at doesn't
*prevent* client code starting on a threshold *and* using start_at, even if it seems to us like a strange idea.
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
Handshake between application and library
Do alsa lib assume all read/write must only call after calling snd_pcm_sw_params() ?
It seem that proposed start_at() can only be call in SND_PCM_STATE_PREPARED and should fail when stream is already running
Are there any mean to cancel the scheduled snd_pcm_start_at ?
Seem there is no check when the application call snd_pcm_start_at() multiple times
Preventing the use of both requires us to show why it's never a useful
idea, decide on policy (what do happens when client code tries to use both), and implement that policy. I'd rather just leave it as 'possible' :at()