Re: Audio drivers- Difference between start_output and trigger_output.

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

Disclaimer: it's almost 10 years since I last touched our audio
framework :)

On Wed, Dec 14, 2011 at 23:23:31 +1100, Nat Sloss wrote:

> I have read audio(9) and have looked at several audio drivers.  I was having 
> trouble with btsco and have found it uses start output instead of trigger 
> output.
> 
> So my question is what is the difference between start output and trigger 
> output? 
>
> Is block,blksize in start output equivalent to start,blksize in trigger 
> output?

There's some minimal description in audio(9) manpage.

Driver must supply either start_output or trigger_output.  If
trigger_output is provided it is used instead of start_output.  Check
sys/dev/audio.c - I don't like giving RTFS for an answer, but in this
case it might be faster and easier to read 3 code snippets that refer
trigger_output and start_output than to define the semantic formally.

Informally, you should use trigger_output if you can efficiently
arrange for your DMA engine to process the next chunk of data while
your interrupt routine calls back to audio_pint for even more data.

In this case audio(9) begins playback with trigger_output and in
audio_pint it just throws more data into the ringbuffer.  I guess it's
classic parallel producer/consumer.

If you use start_output instead then audio(9) begins playback with
start_output and in audio_pint it also needs to call start_ouput for
the new chunk.  There's no parallelism.


E.g. for cs4231 we use trigger_output to program the first chunk into
address/count registers and second chunk into next address/next count
registers.  When the first chunk is done hardware automatically loads
"next" registers into "main" registers and proceeds with playback
while interrupt routine reprograms "next" registers with the third
chunk and asks audio_pint to supply more data now that the first chunk
data has been consumed.  Thus for trigger_output you need start, end
and blocksize.

If you can't arrange for such parallelism, you have to use
start_output that takes single block descrbed by block+blocksize and
audio_pint needs to explicitly call start_output again to continue
playback.


I hope I didn't make too many mistakes in this :)

-uwe