On 06/01/15 14:42, Pierre-Louis Bossart wrote:
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.
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' :)
Thanks, -Pierre