On 09/01/15 12:03, Raymond Yau 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.
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
This sounds ok to me - I followed Nick Stoughton's lead on this.
Are there any mean to cancel the scheduled snd_pcm_start_at ?
There is no explicit mechanism in the proposed patch: The pending timer is cancelled if client code attempts to change the stream state. Would you like to see an explicit cancellation API?
Seem there is no check when the application call snd_pcm_start_at() multiple times
The code only allows _one_ start_at timer to be pending. When snd_pcm_start_at() is called, the pending timer (if any) is cancelled (atomically) before being replaced by the new timer.
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()