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