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

[Alexander E. Patrakov]

14.07.2015 08:32, Raymond Yau wrote:
>
>
>     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

<deleted a long quote>

I expected an answer in the form "XXX mW out of YYY, for such-and-such 
buffer and period sizes".

>     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

dmix uses mmap and never advances application pointer on the slave 
(which is a hw device). While each instance of dmix can indeed perform 
mmap-based writes sequentially, what the device sees is not sequential. 
E.g., for two periods and two applications, started simultaneously, the 
sequence is like this:

1st app writes 1st period
1st app writes 2nd period
2nd app overwrites 1st period with the mix
2nd app overwrites 2nd periodwith the mix
hw completes playing 1st period
1st app writes 1st period
2nd app overwrites 1st period with the mix
hw completes playing 2nd period
2nd app writes 2nd period
1st app overwrites 2nd period with the mix
hw completes playing 1st period

...and so on, and we have not considered xruns here, which complicate 
the picture even further. The point is: what the hardware sees is not a 
stream of sequential writes, so the no-rewind flag is not appropriate.

And it is never notified about the application pointer, so the flag is 
definitely not appropriate again.

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

No, see above.

Regarding dmix rewindability status: dmix is not actually rewindable 
(but pretends to be), and, while (unlike for extplug) I don't see any 
reason why it must be unrewindable, there is no opposition to mark it as 
unrewindable and then call the problem solved.

Regarding PulseAudio: for PATCH 1/4, it is completely irrelevant. 
Pulseaudio wants to be responsive to the events that new streams appear 
and existing ones change software-based volume. Let's suppose that it 
wants to respond in no later than 10 ms (just a made-up number). Then, 
at no point there should be more than 10 ms of buffered audio that 
cannot be replaced. If PulseAudio starts using this new flag, then it 
has to wake up the CPU every 10 ms. I.e. "let the audio DMA engine wake 
up every 0.125 ms, as it does by default, and let the CPU wake up every 
1000 ms unless something important happens (in which case there is a 
rewind)" would be replaced by "let the audio DMA engine wake up once in 
10 ms, and also let the CPU wake up every 10 ms", which is much worse. 
Unfortunately, the patch does not offer a way to say "let the DMA engine 
wake up every 10 ms, and CPU wake up every 1000 ms (and occasionally 
perform rewinds, but leave 10 ms untouched)".

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

Yes, but very carefully. E.g., suppose that the period size is 10 ms. 
Then, this sequence of events is valid, does not produce xruns and does 
not cause the card to play stale data:

0 ms: Application fills 2 periods via mmap, notices the timestamp and 
starts the PCM.
10 ms: Hardware plays out the 1st period and wakes up the application. 
Application writes the 1st period via mmap and notices the timestamp.
20 ms: Hardware plays out the 2nd period and wakes up the application. 
Application writes the 2nd period via mmap and notices the timestamp.
23 ms: Application wakes up for an unrelated reason and notices the 
timestamp. It knows that the sound card still has 17 ms to play, and 10 
ms (one period, as usual for batch/blocktransfer cards) are 
unrewindable. So it rewinds 6 ms and writes new data.
30 ms: Hardware plays out the 1st period and wakes up the application. 
Application writes the 1st period via mmap and notices the timestamp.

... and so on.

-- 
Alexander E. Patrakov