[alsa-devel] [PATCH v2 1/1] alsa-lib: Add snd_pcm_start_at.

[Raymond Yau]

>>
>>
>>>> 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()