[alsa-devel] [RFC PATCH 1/4] ALSA: core: let low-level driver or userspace disable rewinds

[Raymond Yau]

 Add new hw_params flag to explicitly tell driver that rewinds
>> will never be used. This can be used by low-level driver to
>> optimize DMA operations and reduce power consumption.
>> Use this flag only when data written in ring buffer will
>> never be invalidated, e.g. any update of appl_ptr is final.
>>
>> Caveat: there is currently no way to query capabilities without
>> opening a pcm stream, so applications might need to serially
>> open all exposed devices, check what they support by looking at
>> hw_params->info and close them (this is what PulseAudio does so
>> might not be an issue)
>>
>
> How about spdif->status AES0_NONAUDIO is set when AC3 passthrough SPDIF ?


>
> 1. What amount of power-saving are we talking about, for Intel chips?
> (ideally, this should be in the commit message)
>

Refer to HDA043-A

Energy efficient audio buffering and dynamic FIFO limit change

3.3.11 Offset 12h: GCAP2 –Global Capabilities 2

FIFO Size Change (FIFOSC) This bit isRO

if GCAP2.EEAC = 0.

In static case (GCAP2.EEAC = 1 and GCAP2.DFFLCC = 0), this bit will only
have effect before the first time RUN bit is set. Software must not attempt
to write this bit, unless EECAP.EEAC bit is set. HW will treat this bit as
read -only if the capability is not supported
.
In dynamic case (GCAP2.EEAC = 1 and GCAP2.DFFLCC = 1), on top of supporting
the static behavior describe above, this bit can also be used to
communicate the dynamic change request in FIFO size between SW and HW when
the stream is active


3.3.41 Offset 90: {IOB}SDnFIFOS – Input/Output/Bidirectional Stream
Descriptor n FIFO Size

When HW supports EE Audio capability,the FIFOS this value will represent
the minimum size of cyclic buffer for efficient HW operation


Do application need to know driver is using static or dynamic case ?

is the minimum size of cyclic buffer for efficient HW operation larger than
current hw params (period_bytes_min * periods_min) ?



> 2. Shouldn't SND_PCM_APPEND (the mode used by dmix and friends) be also
> made incompatible with this flag, because, when mixing, it essentially
> overwrites incompletely-mixed data, i.e. rewinds without saying the word
> "rewind"? Shouldn't all other kinds of freewheeling be made incompatible
> with this flag, because the card, essentially, is never told about the
> application pointer? Or is this a userspace-only concern?
>

if SND_PCM_APPEND use fmode = O_APPEND when snd_device_open(), this seem
support sequential write only and no random write

Do it mean pulseaudio cannot rewind dmix as dmix alway append data to hw
device ?


>
> 3. I have not seen any justification for the drastic measure of making a
> DMA-based device completely unrewindable. Maybe a more polite "please make
> this a batch/blocktransfer card" request, thus disallowing only sub-period
> rewinds, would still be useful for powersaving, without killing dmix.
>

Can those non-interleaved access pcm device with two periods support rewind
?