Master Plan on rewinding

Master Plan on rewinding

[Alexander E. Patrakov]

Hello.

(TL;DR: nothing really new except the strawman proposal about threads 
and the note about interaction of variable sample rate with rewindability)

As Takashi Iwai told me that the audio miniconference is for discussion 
only, and not for presentation of anything, I guess that I need to 
present the plans and options now. That's why this e-mail. The goal 
here, besides merely presenting the plan, is to identify points that 
everyone agrees upon, so that they are not discussed pointlessly at the 
miniconference. Also, this e-mail serves as a justification for the 
pending seemingly-destructive work.

First, the status quo. If anyone disagrees with the facts below, please 
complain loudly, before I make any conclusions!

1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA 
plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28, 
but in some cases snd_pcm_rewindable() still returns wrong results.

2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - 
(snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is 
needed due to reasons that I don't completely understand, but one of 
them is imprecise reporting of the hardware pointer, and another one is 
that the hardware transfers several bytes at a time, and the bytes we 
need to overwrite may be already cached by the hardware.

3. On the hw plugin, I could demonstrate two other bugs regarding 
snd_pcm_rewindable(): stale data and bogus negative return values.

4. There are ALSA plugins like "a52" or the "bluetooth" plugin from old 
version of bluez that return non-zero for snd_pcm_rewindable() and 
snd_pcm_rewind, but actually don't rewind, and where rewinding is almost 
impossible to implement (e.g. because this would seemingly involve 
unsending of already-sent bluetooth packets). See below why "almost", 
you need to search for "Alternative strawman proposal".

5. PulseAudio contains a workaround for non-rewindability of the a52 
plugin that also happens to apply to other ioplug-based plugins. 
However, this workaround does not match extplug-based plugins (including 
"dca"), and my patch extending the workaround has been rejected with the 
argument that this has to be fixed in ALSA.

6. The rate plugin has been made non-rewindable in alsa-lib 1.0.28 
because the old implementation was wrong and no simple fix exists.

7. Issues regarding rewindability of PulseAudio internals such as 
virtual sinks will be discussed separately.

And now the topics for discussion.

My immediate plan is to fix (3) and, if anyone replies to the rewind 
safeguard proposal, maybe start fixing (2) from the alsa-lib side.

For all proposals below, unless I say otherwise, I intend to write the 
required alsa-lib code myself if the proposal is accepted.

=== On the rewind safeguard ===

The consensus is that rewind_safeguard is a workaround for an ALSA bug. 
This information should come from snd_pcm_rewindable() from the hw 
plugin. I.e., on a hw device, it should not be equal to 
snd_pcm_mmap_hw_avail(). While the method of dealing with stale data and 
negative returns is obvious to me, I am not completely sure about the 
safeguard. Where should this value come from?

Proposal (credit goes to Raymond Yau): the safeguard should be ideally 
equal to the granularity of hardware pointer updates. However, we don't 
know this granularity a priori, and cannot know this because nobody will 
find out this information for old cards. Since we can't get this, let's 
instead use the upper bound: the minimum possible period size for the 
given sample rate, sample format and the number of channels.

On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo, 
the granularity is 32 bytes (= 8 samples), and I get the pointer 
granularity of 64 bytes (=16 samples) over HDMI. The minimum period size 
is 32 samples in both cases. Thus Raymond's method will overestimate the 
required safeguard on my cards, but it is still better than no safeguard 
at all, and less than the hard-coded value in PulseAudio.

On ymfpci, the pointer granularity is 5 ms, thus the value currently 
hard-coded in PA is insufficient. If I understand the card's limitations 
correctly, Raymond's method will yield the spot-on result for this card.

For the allegedly existing cards where the pointer granularity is always 
the same as the period size, Raymond's method will not work. However, I 
don't know any concrete example of such card (I didn't look at 
snd-firewire in detail, though). And in any case, my opinion is that 
this "pointer granularity = period size" limitation on such cards can be 
treated as a driver bug that needs to be fixed (by someone who knows the 
driver, not by me). On cards where pointer updates happen only on 
interrupts, the driver should not configure the card in such a way that 
one period visible to the userspace corresponds to one interrupt. 
Instead, it should always configure the card for the minimum possible 
period size, and report only part of the period interrupts to 
period_elapsed(). I.e.: userspace asked for 2 periods 64 ms each, but 
let's configure the card for, say, 64 periods 2 ms each, and use the 
"extra" interrupts only for updating the pointer.

Hopefully, the above heuristic and driver fix will also let PulseAudio 
get rid of special treatment of the "batch" cards, simply because they 
(in the "pointer granularity = period size" definition which is 
currently used in PulseAudio) will no longer exist.

If the heuristic (or something else) is accepted, then the question 
remains how to enable the use of snd_pcm_rewindable in PulseAudio. The 
problem is compatibility with older ALSA versions that, let me remind 
you, crash if snd_pcm_rewindable is called. I don't have proposals or 
opinions here. The obvious options are: compile-time alsa-lib version 
check with fallback to old code on buggy versions, run-time alsa-lib 
version check with the same fallback, add a (both compile-time and 
run-time) hard requirement of a fully-fixed alsa-lib version, or do 
nothing at all.

Possible discussion: alternative heuristics and, as mentioned, migration 
path in PulseAudio.

=== On non-rewindability of the rate plugin ===

I intend to write a rewindable resampler eventually, but don't have time 
now. I understand that it is an important task, but issues below (and 
the dayjob which you can change by offering me a new one) have higher 
priority for me. However, I want everyone to understand the following 
point now:

"The resampler has to be written from scratch for the reasons explained 
in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and 
similar arguments apply to all other kinds of sound processing code that 
needs history."

For PulseAudio, it is also needed to figure out the desired interaction 
between variable rate and rewindability. Should rewinding other than 
"discard everything completely" be allowed at all on variable rate 
streams when the rewind crosses the sample rate change point? I.e., 
write 100 samples, change rate, write 50 samples, rewind 100 samples, 
what should be the resulting rate? Should we special-case small changes 
vs big ones?

Slightly off-topic, but still a discussion point.

=== On possibly-incomplete rewindability of the file plugin ===

The file plugin has quite hairy code involving the use of the write 
buffer. I have not verified its correctness or studied the code in 
detail. Anyway, it looks like it allows rewinding over that buffer only, 
even though its slave may allow rewinding further. If true, this would 
make the apparent rewindability useless, as the applications depend on 
being able to rewind almost everything, and won't like the 
apparently-random limitation (random because it depends on some obscure 
"wbuf" implementation detail).

I think that the plugin has to be changed to avoid this limitation if it 
really exists (which I still need to verify). Namely, I propose keeping 
a shadow copy of the slave's buffer, and, at the beginning of each API 
call, querying the slave about its hardware pointer. Only the part of 
the shadow buffer that corresponds to the distance covered by the 
slave's hardware pointer since the last call has to be written to the file.

The same applies to recording. As the code is much simpler there, it is 
obvious that the problem exists: if one rewinds in order to look at the 
past recorded samples again, the plugin will read further samples from 
the file instead of supplying the already-looked-at samples. The same 
solution with the slave hardware pointer should be applicable.

The possible discussion here amounts to suggesting alternative proposals.

=== On bogus rewindability of ladspa and extplug plugins ===

For ioplug, see below, because the situation is different enough.

Neither LADSPA nor snd_pcm_extplug_t have an API that allows to tell the 
corresponding plugin to forget the last N samples. We cannot fix LADSPA, 
as it is beyond our control. And we cannot really fix extplug, because 
this just means moving the problem down one level. External libraries 
(which are depended upon by the extplug-based plugins) are almost 
universally not rewindable, are beyond our control, and will not be made 
rewindable, because rewindability is hard and is not needed by anyone 
except ALSA and PulseAudio. Still, neither .rewindable not .rewind 
currently return 0.

So, I'd argue that the only correct result from snd_pcm_rewindable() is 
0 for ladspa and extplug plugins. However, right now, they forward the 
result from the slave. This needs to be fixed, and I have a patch.

With snd_pcm_rewind(), the situation is a bit different. It, obviously, 
does nothing to tell the LADSPA or extplug plugin that the rewind 
happened (because it can't). It also performs a rewind on the slave. So, 
assuming that the rewind succeeds and the DSP algorithm in the plugin 
uses N samples from the past, we'll end up with the output of the 
correct duration but with N corrupted samples. Not ideal. But if we 
don't perform the rewind at all and return 0, we'll end up with 
regressing PulseAudio: huge latency when applying software volume 
changes or starting new streams. By setting up the large buffer size, it 
essentially assumes that any rewind will succeed.

So, my hackish proposal is: make the .rewindable callbacks on ladspa and 
extplug return 0, keep the current implementation of the .rewind 
callback for compatibility with the current versions of PulseAudio, 
document this hack. I already have patch for this, will send out if we 
agree that the proposal is good.

An alternative proposal (that I would implement if the proposal above is 
rejected and someone actively confirms this one - but I don't like it) 
would be to keep the current versions of the .rewindable and .rewind 
callbacks and add new versions of them (and new user-visible ALSA API) 
for the situation when imperfect results are unacceptable.

A completely strawman proposal would be to introduce a low-latency 
thread, see below in the ioplug section.

Same for .forwardable and .forward.

Any other alternatives that I missed?

=== On bogus rewindability of some ioplug-based plugins ===

Ioplug-based plugins currently report rewindability according to the 
same "appl.ptr - hw.ptr" rule that is used by the hw plugin. However, 
this is incorrect.

In fact, there are two types of ioplug-based plugins. The jack plugin 
does not even have a .transfer callback, and does all the work of 
irrevocably submitting samples to the JACK server in a thread. So, it is 
almost completely rewindable (with that "almost" being equal to JACK 
buffer size). Proposal: keep this logic for all plugins without the 
.transfer callback. Expose the JACK buffer size as the minimum period 
size. Then the same rule proposed in the section about the hw plugin 
will work for .rewindable.

Other plugins do their irrevocable work in the .transfer callback and 
thus are not really rewindable. Proposal: return 0 from .rewindable and 
rewind ioplug callbacks for all plugins with a .transfer callback (but 
see the next section for an amendment). Document that the best practice 
is to have no .transfer callback.

Alternative strawman proposal (speculative): if a .transfer callback 
exists, call it from an alsa-lib-created thread (not from 
snd_pcm_writei!) at the last possible moment, using the least possible 
amount of data (that truly cannot be rewound) in the mmap-style buffer. 
The new mantra is: .transfer is the thing that moves the hardware 
pointer. This way, previously non-rewindable plugins could become 
rewindable. Not sure if this is possible without changing the ABI or 
possible at all, though - it essentially forces all plugins to declare 
mmap support. Also not sure what to do with the .pointer callback.

For the strawman proposal, the benefit is a possibility to have dmix on 
top of a52 (because freewheeling will now work), the downside is that 
all programs (not only those intending to do rewinds) now pay the cost 
of the background low-latency thread. Can we avoid this (e.g. with a new 
flag for snd_pcm_open), so that only programs that intend to do rewinds 
pay the price? Can this new flag apply to the batch hw drivers? Won't 
that inflate the test matrix for plugin code?

For discussion: do we implement the first proposal or try the strawman 
proposal? Any other suggestions regarding ioplug internals? Anyone else 
has a problem with two completely different interfaces (with and without 
.transfer) being exposed under the same ioplug framework?

=== On the pulse plugin ===

PulseAudio natively supports rewinding on the wire. However, the 
ioplug-based plugin doesn't. It pretends that it rewound something, but 
always passes 0, 0 as the last two parameters to pa_stream_write(). 
That's bad.

It looks possible (but I haven't checked) to figure out the correct 
arguments (i.e. to detect the rewinds done before the call to 
snd_pcm_writei) by looking at the application pointer. This way, it 
looks possible to support rewinds, but does not look possible to get the 
correct result (and not the result implied by the circular-buffer model) 
from the snd_pcm_rewindable() function.

Also, we apply proposals from the previous section, we'll either end up 
with a plugin that is truly non-rewindable and doesn't pretend to be 
rewindable, or (with a strawman proposal) a rewindable plugin that 
forces low latency on the PulseAudio side and causes a lot of wakeups. 
Both situations are suboptimal.

So, I see no way around adding the .rewind and .rewindable callbacks to 
snd_pcm_ioplug_callback, and treating the plugins with them as 
rewindable. I guess .forward and .forwardable should be added, too.

For discussion: do we do the above or declare that ioplug is not really 
a suitable infrastructure for the pulse plugin? What other alternatives 
can be proposed?

=== On communication of non-rewindability to the program ===

PulseAudio attempts to use timer-based scheduling and rewinds. It makes 
a big hardware buffer in expectation that it will be able to rewind - 
with the exception of a workaround for ioplug-based plugins. It should 
not set big latency for non-rewindable plugins, but currently has no 
idea how to get this bit of information. See 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-April/020457.html 
for the initial problem statement.

If all of the proposals above are implemented, then we'll be at a point 
where each ALSA plugin is either almost fully rewindable, or not 
rewindable at all. So, contrary to the end of 
http://permalink.gmane.org/gmane.linux.alsa.devel/122191 , I think we 
need just snd_pcm_hw_params_is_seekable() (or rename it if you wish) 
with an essentially boolean result.

For discussion:

1. Decide, finally, on this bit of API, so that I can start working.

2. Decide what to do with old alsa-lib versions in PulseAudio. I.e. 
transition plan.

=== On the programmer expectations ===

(social issue)

Some people, including at least Andrew Eikum and Clemens Ladisch, at 
least once in the past expressed the opinion that amounts to "any plugin 
that does not allow random access is, as far as the ALSA API is 
concerned, buggy" (quoting 
http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ), i.e. they 
are maybe asking for the impossible. We need to do something about that. 
Choices:

1. Document clearly that there exist non-rewindable plugins, and that it 
is not a bug until someone implements a working time machine.

2. Implement a strawman proposal with the background low-latency thread 
if it is doable (and I am not sure that it is doable).

3. Remove ioplug, extplug and ladspa as unfixable, fix the rate and 
adpcm plugins (or remove adpcm). Do something about pulse and jack 
because they rely on the to-be-removed ioplug infrastructure. Then all 
remaining plugins will indeed be fully rewindable.

4. Something else?

Sorry for the negative tone here, I know I am bad at formulating and 
resolving social issues.

=== Conclusion ===

When all the proposals are implemented, we'll have correct 
implementations of the rewind operation in all plugins (where "return 0" 
counts as correct), and "return 0" only where it is truly unavoidable. 
PulseAudio will be able to use all of that, and avoid doing rewinds on 
non-rewindable plugins. On this positive note, I'd like to finish 
writing this long e-mail.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Tanu Kaskinen]

On Sun, 2014-09-07 at 21:16 +0600, Alexander E. Patrakov wrote:
> === On non-rewindability of the rate plugin ===
> 
> I intend to write a rewindable resampler eventually, but don't have time 
> now. I understand that it is an important task, but issues below (and 
> the dayjob which you can change by offering me a new one) have higher 
> priority for me. However, I want everyone to understand the following 
> point now:
> 
> "The resampler has to be written from scratch for the reasons explained 
> in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and 
> similar arguments apply to all other kinds of sound processing code that 
> needs history."
> 
> For PulseAudio, it is also needed to figure out the desired interaction 
> between variable rate and rewindability. Should rewinding other than 
> "discard everything completely" be allowed at all on variable rate 
> streams when the rewind crosses the sample rate change point? I.e., 
> write 100 samples, change rate, write 50 samples, rewind 100 samples, 
> what should be the resulting rate? Should we special-case small changes 
> vs big ones?

This last paragraph isn't related to the rate plugin, right? So you're
talking about PulseAudio internals only? If so, perhaps the best
approach would be to make the current stream buffer contents
non-rewindable when a rate change occurs, at least until someone points
out a real use case where it is important to be able to rewind past rate
change points in the buffer. Without any example use cases, I don't feel
qualified to answer the question what should happen if a rewind crosses
a rate change point (or possibly several!).

Another question is that should we do something to previously buffered
stream data when the rate changes. If the audio rate changes completely,
e.g. from 44.1 kHz to 8 kHz, any previously buffered audio was probably
meant to be played at 44.1 kH, but with the current code it will be
played at 8 kHz. I don't know if there are any applications that (ab)use
the dynamic rate feature this way, though. Maybe we could just document
that the dynamic rate feature is only meant for small adjustments.

-- 
Tanu

Re: Master Plan on rewinding

[Alexander E. Patrakov]

08.09.2014 00:38, Tanu Kaskinen wrote:
> On Sun, 2014-09-07 at 21:16 +0600, Alexander E. Patrakov wrote:
>> === On non-rewindability of the rate plugin ===
>>
>> I intend to write a rewindable resampler eventually, but don't have time
>> now. I understand that it is an important task, but issues below (and
>> the dayjob which you can change by offering me a new one) have higher
>> priority for me. However, I want everyone to understand the following
>> point now:
>>
>> "The resampler has to be written from scratch for the reasons explained
>> in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and
>> similar arguments apply to all other kinds of sound processing code that
>> needs history."
>>
>> For PulseAudio, it is also needed to figure out the desired interaction
>> between variable rate and rewindability. Should rewinding other than
>> "discard everything completely" be allowed at all on variable rate
>> streams when the rewind crosses the sample rate change point? I.e.,
>> write 100 samples, change rate, write 50 samples, rewind 100 samples,
>> what should be the resulting rate? Should we special-case small changes
>> vs big ones?
>
> This last paragraph isn't related to the rate plugin, right?

Right.

>  So you're
> talking about PulseAudio internals only?

Yes, in the last paragraph only.

> If so, perhaps the best
> approach would be to make the current stream buffer contents
> non-rewindable when a rate change occurs, at least until someone points
> out a real use case where it is important to be able to rewind past rate
> change points in the buffer. Without any example use cases, I don't feel
> qualified to answer the question what should happen if a rewind crosses
> a rate change point (or possibly several!).
>
> Another question is that should we do something to previously buffered
> stream data when the rate changes. If the audio rate changes completely,
> e.g. from 44.1 kHz to 8 kHz, any previously buffered audio was probably
> meant to be played at 44.1 kH, but with the current code it will be
> played at 8 kHz. I don't know if there are any applications that (ab)use
> the dynamic rate feature this way, though. Maybe we could just document
> that the dynamic rate feature is only meant for small adjustments.

Thanks for the feedback. Let's see if others say anything else on this 
topic.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Clemens Ladisch]

Alexander E. Patrakov wrote:
> The consensus is that rewind_safeguard is a workaround for an ALSA bug.

I do not agree with this consensus.

> This information should come from snd_pcm_rewindable() from the hw
> plugin. I.e., on a hw device, it should not be equal to
> snd_pcm_mmap_hw_avail().  [...]
> the safeguard should be ideally equal to the granularity of hardware
> pointer updates.

When snd_pcm_rewindable() is called, it uses the last reported hardware
pointer position, which is the boundary between safe-to-rewrite and
already-used data.  Subtracting the amount of one pointer update step
makes it safe for the next pointer update, but it is not known how much
time will elapse until the hardware does this update.  This time might
be too small for the software to have any chance, or even zero, but it
is also possible that there is still enough time to do the rewriting up
until the reported boundary.  And if the software is too slow, it is
even possible that two or more pointer updates happen, which would have
required a larger safeguard.

In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of
date, but due to the real-time nature of hardware pointer updates, it is
not possible to define a safeguard that would be more correct.  Writing
the buffer near the DMA pointer is always racy.

The only somewhat reliable way to determine if a rewrite is successful
is to check _afterwards_ whether the hardware pointer has advanced by
too much.

> [...] On cards where pointer updates happen only on interrupts, the
> driver should not configure the card in such a way that one period
> visible to the userspace corresponds to one interrupt. Instead, it
> should always configure the card for the minimum possible period
> size, and report only part of the period interrupts to period_elapsed().

Such stupid DMA controllers are typically found on mobile devices, which
cannot afford extraneous interrupts.

> === On the programmer expectations ===
>
> Some people, including at least Andrew Eikum and Clemens Ladisch, at
> least once in the past expressed the opinion that amounts to "any
> plugin that does not allow random access is, as far as the ALSA API is
> concerned, buggy" (quoting http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ),
> i.e. they are maybe asking for the impossible.

This was merely a description of the current API and its implementation,
which assume that all devices/plugins have a rewritable ring buffer.
I am fully aware that this assumption is wrong.


Regards,
Clemens

Re: Master Plan on rewinding

[David Henningsson]

On 2014-09-07 17:16, Alexander E. Patrakov wrote:
> Hello.
>
> (TL;DR: nothing really new except the strawman proposal about threads
> and the note about interaction of variable sample rate with rewindability)
>
> As Takashi Iwai told me that the audio miniconference is for discussion
> only, and not for presentation of anything, I guess that I need to
> present the plans and options now. That's why this e-mail. The goal
> here, besides merely presenting the plan, is to identify points that
> everyone agrees upon, so that they are not discussed pointlessly at the
> miniconference. Also, this e-mail serves as a justification for the
> pending seemingly-destructive work.
>
> First, the status quo. If anyone disagrees with the facts below, please
> complain loudly, before I make any conclusions!
>
> 1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA
> plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28,
> but in some cases snd_pcm_rewindable() still returns wrong results.

I don't know if we ever tried snd_pcm_rewindable() in PulseAudio.

> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames -
> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is
> needed due to reasons that I don't completely understand, but one of
> them is imprecise reporting of the hardware pointer, and another one is
> that the hardware transfers several bytes at a time, and the bytes we
> need to overwrite may be already cached by the hardware.

Pierre added the rewind safeguard due to DMA controller problems. IIRC, 
some DMA controllers go nuts (such as breaking the stream, causing 
interrupt storms, or something else seriously buggy) when trying to 
write to data that the DMA controller is just about to transfer. Pierre 
(now cc:ed) would know more about this than I do, though.

In my world, since this is a very hardware near problem, ALSA rather 
than PulseAudio should take these kinds of problems into account when 
reporting back snd_pcm_rewindable() so PulseAudio does not have to.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Master Plan on rewinding

[Raymond Yau]

> > The consensus is that rewind_safeguard is a workaround for an ALSA bug.
>
> I do not agree with this consensus.
>
> > This information should come from snd_pcm_rewindable() from the hw
> > plugin. I.e., on a hw device, it should not be equal to
> > snd_pcm_mmap_hw_avail().  [...]
> > the safeguard should be ideally equal to the granularity of hardware
> > pointer updates.
>
> When snd_pcm_rewindable() is called, it uses the last reported hardware
> pointer position, which is the boundary between safe-to-rewrite and
> already-used data.  Subtracting the amount of one pointer update step
> makes it safe for the next pointer update, but it is not known how much
> time will elapse until the hardware does this update.  This time might
> be too small for the software to have any chance, or even zero, but it
> is also possible that there is still enough time to do the rewriting up
> until the reported boundary.  And if the software is too slow, it is
> even possible that two or more pointer updates happen, which would have
> required a larger safeguard.
>
> In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of
> date, but due to the real-time nature of hardware pointer updates, it is
> not possible to define a safeguard that would be more correct.  Writing
> the buffer near the DMA pointer is always racy.
>
> The only somewhat reliable way to determine if a rewrite is successful
> is to check _afterwards_ whether the hardware pointer has advanced by
> too much.

snd_pcm_rewindable is properly not any SAFE value for rewind, it should
return zero for those hardware which don't support rewind(e.g, non
interleaved or cs46xx)

It is just a theoretical value for rewind since the application don't
rewrite immediately

So the application need to estimate the safe guard value from the
processing time of  the amount of data need to be reprocess /rewrite and
CPU speed

Should pulseaudio enable timer scheduling only on those cards which support
disable of period interrupt （e.g. hda-Intel and oxygen )?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Master Plan on rewinding

[Alexander E. Patrakov]

08.09.2014 02:51, Clemens Ladisch wrote:
> Alexander E. Patrakov wrote:
>> The consensus is that rewind_safeguard is a workaround for an ALSA bug.
>
> I do not agree with this consensus.

OK, disagreements are what this thread is for :)

>
>> This information should come from snd_pcm_rewindable() from the hw
>> plugin. I.e., on a hw device, it should not be equal to
>> snd_pcm_mmap_hw_avail().  [...]
>> the safeguard should be ideally equal to the granularity of hardware
>> pointer updates.
>
> When snd_pcm_rewindable() is called, it uses the last reported hardware
> pointer position, which is the boundary between safe-to-rewrite and
> already-used data.  Subtracting the amount of one pointer update step
> makes it safe for the next pointer update, but it is not known how much
> time will elapse until the hardware does this update.  This time might
> be too small for the software to have any chance, or even zero, but it
> is also possible that there is still enough time to do the rewriting up
> until the reported boundary.  And if the software is too slow, it is
> even possible that two or more pointer updates happen, which would have
> required a larger safeguard.

I disagree with the words "boundary between safe-to-rewrite and 
already-used data". They describe a point that hardware knows, but 
software cannot know. My viewpoint is that, even with a perfect 
scheduler, known-safe-to-rewrite and known-already-used data are not 
separated with a point. See below for an example.

You indeed have a strong argument for keeping the safeguard in 
PulseAudio as a protection against scheduler glitches, but look what 
happens on ymfpci. Having read David's email, I understand that it is 
not the same reason why the safeguard has been originally added.

On ymfpci, interrupts (that don't correspond 1:1 to periods) happen 
every 5 ms, and pointer (which is a hardware register) is updated only 
during interrupts by the hardware.

|---------|---------P----h----p---------|-a-------|---------|

Here each character corresponds to 0.5 ms, "-" means nothing 
interesting, "|", "P" and "p" mark interrupt positions, "h" marks the 
place where the card reads the sound data from (i.e. the true boundary 
between safe-to-rewrite and already-used data). Thus, the interrupt at 
"P" has already happened, but the interrupt at "p" hasn't. "a" is the 
application write pointer.

So, what should alsa-lib return for snd_pcm_avail() and 
snd_pcm_rewind()? The driver only knows that "P" is already used, can 
infer that "p" isn't used yet, and knows nothing about samples in the 
middle.

For snd_pcm_avail(), it can only say that the application may only write 
up to "P" from the left. Everything else would be a possible lie leading 
to not-yet-played data possibly being overwritten.

For snd_pcm_rewindable(), it can only say that the application may try 
to go to "p" from the right. Everything further to the left is at risk 
of being already-played, even with a perfect scheduler and infinitely 
fast CPU.

> In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of
> date, but due to the real-time nature of hardware pointer updates, it is
> not possible to define a safeguard that would be more correct.  Writing
> the buffer near the DMA pointer is always racy.

Correct. The problem is that, on some cards, the uncertainty here 
(described above) is an order of magnitude bigger than typical scheduler 
glitches, and depends on sound card hardware. I don't want to introduce 
an unnecessarily-big safeguard for all sound cards because of a few bad 
ones.

So it looks like we need both the hardware-independent safeguard in 
PulseAudio (against scheduler glitches) and the hardware-dependent 
safeguard in alsa-lib (against known imprecise reporting by the card).

> The only somewhat reliable way to determine if a rewrite is successful
> is to check _afterwards_ whether the hardware pointer has advanced by
> too much.

PulseAudio does that in addition to the safeguard.

>> [...] On cards where pointer updates happen only on interrupts, the
>> driver should not configure the card in such a way that one period
>> visible to the userspace corresponds to one interrupt. Instead, it
>> should always configure the card for the minimum possible period
>> size, and report only part of the period interrupts to period_elapsed().
>
> Such stupid DMA controllers are typically found on mobile devices, which
> cannot afford extraneous interrupts.

Thanks for the information, I didn't know that, and hereby retract the 
quoted proposal.

Still, to support this type of stupid DMA controllers properly, we need 
a vocabulary of such weirdnesses and an agreed-upon way to communicate 
them from the kernel to userspace. I don't think that I can build such 
vocabulary.

>
>> === On the programmer expectations ===
>>
>> Some people, including at least Andrew Eikum and Clemens Ladisch, at
>> least once in the past expressed the opinion that amounts to "any
>> plugin that does not allow random access is, as far as the ALSA API is
>> concerned, buggy" (quoting http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ),
>> i.e. they are maybe asking for the impossible.
>
> This was merely a description of the current API and its implementation,
> which assume that all devices/plugins have a rewritable ring buffer.
> I am fully aware that this assumption is wrong.

OK. Now I see that in your case it was a misinterpretation from my side 
- sorry for that! But this doesn't cancel the attitude "if a function is 
documented without any caveats, it must always work, usefully" that I 
have seen from others. So I'll put a documentation patch on my TODO list.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Lars-Peter Clausen]

On 09/07/2014 05:16 PM, Alexander E. Patrakov wrote:
[...]
> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames -
> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is needed
> due to reasons that I don't completely understand, but one of them is
> imprecise reporting of the hardware pointer, and another one is that the
> hardware transfers several bytes at a time, and the bytes we need to
> overwrite may be already cached by the hardware.
>

Also at the time you will process the result form snd_pcm_avail() will be 
more than what was reported as the audio DMA keeps going in the background.

[...]
> For the allegedly existing cards where the pointer granularity is always the
> same as the period size, Raymond's method will not work. However, I don't
> know any concrete example of such card (I didn't look at snd-firewire in
> detail, though). And in any case, my opinion is that this "pointer
> granularity = period size" limitation on such cards can be treated as a
> driver bug that needs to be fixed (by someone who knows the driver, not by
> me). On cards where pointer updates happen only on interrupts, the driver
> should not configure the card in such a way that one period visible to the
> userspace corresponds to one interrupt. Instead, it should always configure
> the card for the minimum possible period size, and report only part of the
> period interrupts to period_elapsed(). I.e.: userspace asked for 2 periods
> 64 ms each, but let's configure the card for, say, 64 periods 2 ms each, and
> use the "extra" interrupts only for updating the pointer.
>

There are quite a few ASoC drivers that do have this restriction. For some 
of the drivers the restriction comes from the hardware itself for others it 
is while the hardware in theory supports it nobody bothered so far to 
implement this.

I do not agree that this should be treated as a driver bug and that those 
drivers should increase the interrupt rate. Mainly because this is policy 
and the interrupt rate is configured by the application by setting the 
period size and the driver should not have to guess what kind of latency 
requirements the application has. If the application has lower latency 
requirements it needs to set a smaller period size. Unnecessarily increasing 
the interrupt rate has for example has a impact on power consumption which 
is something you'd like to keep low on battery powered devices.

We should though expose the granularity with which the pointer is updated to 
userspace so it can make educated decisions on how to configure the period size.

- Lars

Re: Master Plan on rewinding

[David Henningsson]

On 2014-09-07 17:16, Alexander E. Patrakov wrote:
> Hello.
>
> (TL;DR: nothing really new except the strawman proposal about threads
> and the note about interaction of variable sample rate with rewindability)

So, having looked this through another time, it looks like we have three 
categories of ALSA devices, from rewindability point of view:

  1) Not rewindable at all.

  2) Rewindable down to the period size.

  3) Rewindable even further than the nearest period, down to DMA 
transfer sizes or something else. This also requires the .pointer to 
have better granularity than the period size.

So I think any is_seekable() call or flag should indicate whether the 
device is case 1), 2) or 3). And for case 3) perhaps also some indicator 
of the actual rewind granularity and/or safeguard. This should be enough 
for PA to be able to pick a suitable default latency.

Case 1) is simple. Just let snd_pcm_rewindable return 0 and 
snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem 
could be solved by PA having ifdefs depending on alsa-lib version, 
rather than making snd_pcm_rewind and snd_pcm_rewindable behave 
inconsistent.)

For case 2) you seem to suggest to emulate case 3) by using either a 
low-latency thread, or by increasing the number of interrupts from the 
hardware. Either method will inevitably increase power consumption, and 
the former might also increase the risk of glitches. Therefore I think 
this is replacing something bad with something worse, because I would 
value low power consumption higher than better rewinding.

Could we enable this functionality by explicit request by the 
application? Probably. E g, if the application sets a low period size 
but also sets the "disable period interrupts" flag, that could be an 
indicator that it wants lots of interrupts just to update the pointer, 
but nothing else. Maybe that's even the behaviour today (haven't checked).

The low-latency thread approach could be implemented by a separate 
ioplug layer, so that people who want it could open 
"flexiblerewind:plug:hw:0" instead of "plug:hw:0".

However, with my PA hat on, I would still say no to having PA use either 
of those by default, for power consumption reasons.

With that in mind I suggest, just as you, that we add 
.rewind/.rewindable callbacks to the ioplug layer. Any ioplug using 
.transfer needs to implement that if it wants to support rewinding, 
otherwise that ioplug would fall into category 1).

Does that make sense? It was a long email, so I might have missed 
something. :-)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Master Plan on rewinding

[Alexander E. Patrakov]

08.09.2014 13:59, David Henningsson wrote:

(First of all, a big thanks for being the first to talk constructively 
about the important problem of rewindability classes!)

> On 2014-09-07 17:16, Alexander E. Patrakov wrote:
>> Hello.
>>
>> (TL;DR: nothing really new except the strawman proposal about threads
>> and the note about interaction of variable sample rate with
>> rewindability)
>
> So, having looked this through another time, it looks like we have three
> categories of ALSA devices, from rewindability point of view:
>
>   1) Not rewindable at all.
>
>   2) Rewindable down to the period size.
>
>   3) Rewindable even further than the nearest period, down to DMA
> transfer sizes or something else. This also requires the .pointer to
> have better granularity than the period size.
>
> So I think any is_seekable() call or flag should indicate whether the
> device is case 1), 2) or 3). And for case 3) perhaps also some indicator
> of the actual rewind granularity and/or safeguard. This should be enough
> for PA to be able to pick a suitable default latency.

So far, I agree. The big question now is: do we have enough correct data 
from the kernel to decide between cases 2 and 3? I am definitely not 
qualified enough to answer this or to add such interface, though.

> Case 1) is simple. Just let snd_pcm_rewindable return 0 and
> snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem
> could be solved by PA having ifdefs depending on alsa-lib version,
> rather than making snd_pcm_rewind and snd_pcm_rewindable behave
> inconsistent.)

OK. But I don't think that the ifdef proposal is sufficient. If I 
understand correctly, it only covers the "new PA on old alsa-lib" 
problem, because we can't add these ifdefs to old PA. That's still 
progress! But the "keep the old implementation of rewind" was for the 
opposite problem - old PA on new alsa-lib which rightfully refuses to 
rewind.

> For case 2) you seem to suggest to emulate case 3) by using either a
> low-latency thread, or by increasing the number of interrupts from the
> hardware. Either method will inevitably increase power consumption, and
> the former might also increase the risk of glitches. Therefore I think
> this is replacing something bad with something worse, because I would
> value low power consumption higher than better rewinding.

There is a slight misunderstanding above. I indeed proposed (and 
retracted the proposal when I knew that it happens on mobile devices) to 
emulate case 3 in case 2 by increasing the number of interrupts from the 
hardware. The proposal of a low-latency background thread was about 
emulating case 3 on case 1, and, so far, I have not retracted it, but I 
may do so in the future.

As for power consumption increase, the argument is essentially a 
duplicate of the phrase "the downside is that all programs (not only 
those intending to do rewinds) now pay the cost of the background 
low-latency thread" from my original mail. In other words, I partially 
agree. This, if enabled unconditionally, indeed would lead to 
unnecessary power consumption increase for those applications that don't 
use rewinds. But for applications that want low latency or dynamic 
latency, there is no other way to get it, so it is wrong to talk about 
power consumption increase for such applications.

> Could we enable this functionality by explicit request by the
> application? Probably. E g, if the application sets a low period size
> but also sets the "disable period interrupts" flag, that could be an
> indicator that it wants lots of interrupts just to update the pointer,
> but nothing else. Maybe that's even the behaviour today (haven't checked).

A very good idea.

>
> The low-latency thread approach could be implemented by a separate
> ioplug layer, so that people who want it could open
> "flexiblerewind:plug:hw:0" instead of "plug:hw:0".

Also a good idea.

> However, with my PA hat on, I would still say no to having PA use either
> of those by default, for power consumption reasons.

I would also say no, but for a different reason (because, as I wrote 
above, the power-consumption reason is valid only for software that 
never wants to rewind and does not need low/dynamic latency, and PA does 
not fall into this category). My argument is that, in the case of 
PulseAudio, these emulations would just create an unnecessary layer of 
complexity. PulseAudio actively wants to know the device type (via the 
is_seekable() call), so it is reasonable for it to also deal with 
consequences, without the need for additional processing in the driver 
or for an extra thread.

> With that in mind I suggest, just as you, that we add
> .rewind/.rewindable callbacks to the ioplug layer. Any ioplug using
> .transfer needs to implement that if it wants to support rewinding,
> otherwise that ioplug would fall into category 1).
>
> Does that make sense? It was a long email, so I might have missed
> something. :-)

In fact, _I_ missed something when writing the original e-mail. I forgot 
to address your phrase from 
http://permalink.gmane.org/gmane.linux.alsa.devel/122191:

> I understand that you have a mathematically perfect approach to this, as
> well as other algorithms. This would indeed be the best goal, but given
> an imperfect world, where we're forced to choose between
>   1) no rewinding at all
>   2) imperfect rewinding in the sense that it sometimes can produce
> hearable artifacts
>
> ...I'm not sure 1) is always the right choice...

Should we have a snd_pcm_open (or whatever else) flag for accepting 
imperfect rewind results? [anyway, I would say "no" to using it in 
PulseAudio]

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[David Henningsson]

On 2014-09-08 10:46, Alexander E. Patrakov wrote:
> 08.09.2014 13:59, David Henningsson wrote:
>
> (First of all, a big thanks for being the first to talk constructively
> about the important problem of rewindability classes!)
>
>> On 2014-09-07 17:16, Alexander E. Patrakov wrote:
>>> Hello.
>>>
>>> (TL;DR: nothing really new except the strawman proposal about threads
>>> and the note about interaction of variable sample rate with
>>> rewindability)
>>
>> So, having looked this through another time, it looks like we have three
>> categories of ALSA devices, from rewindability point of view:
>>
>>   1) Not rewindable at all.
>>
>>   2) Rewindable down to the period size.
>>
>>   3) Rewindable even further than the nearest period, down to DMA
>> transfer sizes or something else. This also requires the .pointer to
>> have better granularity than the period size.
>>
>> So I think any is_seekable() call or flag should indicate whether the
>> device is case 1), 2) or 3). And for case 3) perhaps also some indicator
>> of the actual rewind granularity and/or safeguard. This should be enough
>> for PA to be able to pick a suitable default latency.
>
> So far, I agree. The big question now is: do we have enough correct data
> from the kernel to decide between cases 2 and 3? I am definitely not
> qualified enough to answer this or to add such interface, though.

I'm quite certain that we don't have enough information coming through 
from the kernel. It's something we need to add if we end up deciding to 
implement hw_params_is_seekable.

>> Case 1) is simple. Just let snd_pcm_rewindable return 0 and
>> snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem
>> could be solved by PA having ifdefs depending on alsa-lib version,
>> rather than making snd_pcm_rewind and snd_pcm_rewindable behave
>> inconsistent.)
>
> OK. But I don't think that the ifdef proposal is sufficient. If I
> understand correctly, it only covers the "new PA on old alsa-lib"
> problem, because we can't add these ifdefs to old PA. That's still
> progress! But the "keep the old implementation of rewind" was for the
> opposite problem - old PA on new alsa-lib which rightfully refuses to
> rewind.
>
>> For case 2) you seem to suggest to emulate case 3) by using either a
>> low-latency thread, or by increasing the number of interrupts from the
>> hardware. Either method will inevitably increase power consumption, and
>> the former might also increase the risk of glitches. Therefore I think
>> this is replacing something bad with something worse, because I would
>> value low power consumption higher than better rewinding.
>
> There is a slight misunderstanding above. I indeed proposed (and
> retracted the proposal when I knew that it happens on mobile devices) to
> emulate case 3 in case 2 by increasing the number of interrupts from the
> hardware. The proposal of a low-latency background thread was about
> emulating case 3 on case 1, and, so far, I have not retracted it, but I
> may do so in the future.

Right. I guess the low-latency background thread can be used to emulate 
3) on top of both 1) and 2).

> This, if enabled unconditionally, indeed would lead to
> unnecessary power consumption increase for those applications that don't
> use rewinds. But for applications that want low latency or dynamic
> latency, there is no other way to get it, so it is wrong to talk about
> power consumption increase for such applications.

Uhm, is the set of applications that want "low or dynamic latency" 
necessarily the same as the set that want rewinds?

But that might be more of an academic question, I guess PA is the only 
one that does rewinds currently. Or are there more apps out there that 
do rewinds?

I'm not sure I buy this point completely, but I can't come up with a 
good counterexample either, so maybe you're right.

> My argument is that, in the case of
> PulseAudio, these emulations would just create an unnecessary layer of
> complexity.  PulseAudio actively wants to know the device type (via the
> is_seekable() call), so it is reasonable for it to also deal with
> consequences, without the need for additional processing in the driver
> or for an extra thread.

Agreed.

>> I understand that you have a mathematically perfect approach to this, as
>> well as other algorithms. This would indeed be the best goal, but given
>> an imperfect world, where we're forced to choose between
>>   1) no rewinding at all
>>   2) imperfect rewinding in the sense that it sometimes can produce
>> hearable artifacts
>>
>> ...I'm not sure 1) is always the right choice...
>
> Should we have a snd_pcm_open (or whatever else) flag for accepting
> imperfect rewind results? [anyway, I would say "no" to using it in
> PulseAudio]

Well, if we had one, and it defaulted to the old behaviour, I suppose 
that would solve the new alsa-lib on old PA problem? But I'm not sure 
it's worth the added complexity.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Master Plan on rewinding

[Alexander E. Patrakov]

08.09.2014 15:26, David Henningsson wrote:
> On 2014-09-08 10:46, Alexander E. Patrakov wrote:
>> 08.09.2014 13:59, David Henningsson wrote:
>>
>> (First of all, a big thanks for being the first to talk constructively
>> about the important problem of rewindability classes!)
>>
>>> On 2014-09-07 17:16, Alexander E. Patrakov wrote:
>>>> Hello.
>>>>
>>>> (TL;DR: nothing really new except the strawman proposal about threads
>>>> and the note about interaction of variable sample rate with
>>>> rewindability)
>>>
>>> So, having looked this through another time, it looks like we have three
>>> categories of ALSA devices, from rewindability point of view:
>>>
>>>   1) Not rewindable at all.
>>>
>>>   2) Rewindable down to the period size.
>>>
>>>   3) Rewindable even further than the nearest period, down to DMA
>>> transfer sizes or something else. This also requires the .pointer to
>>> have better granularity than the period size.
>>>
>>> So I think any is_seekable() call or flag should indicate whether the
>>> device is case 1), 2) or 3). And for case 3) perhaps also some indicator
>>> of the actual rewind granularity and/or safeguard. This should be enough
>>> for PA to be able to pick a suitable default latency.
>>
>> So far, I agree. The big question now is: do we have enough correct data
>> from the kernel to decide between cases 2 and 3? I am definitely not
>> qualified enough to answer this or to add such interface, though.
>
> I'm quite certain that we don't have enough information coming through
> from the kernel. It's something we need to add if we end up deciding to
> implement hw_params_is_seekable.

OK, but, given that we need this interface in order to avoid seeking on 
the DTS encoder (and to avoid creating a big buffer on it), I'd rather 
have this sooner than later. As a compromise, let's design the API with 
case 2 in mind, but only return cases 1 and 3 until we have enough 
information from the kernel to detect case 2 reliably. And, unless 
someone sends out a constructive proposal, let's defer the discussion of 
case 2 detection to the miniconference.

(And users do complain about rewinding on dcaenc, because this rewind 
creates one or two invalid DTS frames in the middle of every volume 
change, and some receivers are slow to resynchronize).

>> This, if enabled unconditionally, indeed would lead to
>> unnecessary power consumption increase for those applications that don't
>> use rewinds. But for applications that want low latency or dynamic
>> latency, there is no other way to get it, so it is wrong to talk about
>> power consumption increase for such applications.
>
> Uhm, is the set of applications that want "low or dynamic latency"
> necessarily the same as the set that want rewinds?

It is a superset. Applications that want low latency don't necessarily 
want rewinds, but they want high interrupt rate => high power 
consumption anyway. Applications that want dynamic latency will do 
rewinds, because this is the only way to get it, except always 
defaulting to sometimes-unnecessary low latency.

>
> But that might be more of an academic question, I guess PA is the only
> one that does rewinds currently. Or are there more apps out there that
> do rewinds?

Right now it is indeed an academic question. However, earlier in this 
year I was contacted by Andrew Eikum who was trying to use rewinds in 
Wine and insisted that it is an ALSA bug when I told him that they 
cannot work on the default device. I am not sure whether I convinced 
him, because I did not use the "unsend bluetooth packets" wording back 
then. I cannot quote him now, because this was via IM, so quoting would 
be impolite. And, the log is on the other PC anyway.

> I'm not sure I buy this point completely, but I can't come up with a
> good counterexample either, so maybe you're right.
>
>> My argument is that, in the case of
>> PulseAudio, these emulations would just create an unnecessary layer of
>> complexity.  PulseAudio actively wants to know the device type (via the
>> is_seekable() call), so it is reasonable for it to also deal with
>> consequences, without the need for additional processing in the driver
>> or for an extra thread.
>
> Agreed.
>
>>> I understand that you have a mathematically perfect approach to this, as
>>> well as other algorithms. This would indeed be the best goal, but given
>>> an imperfect world, where we're forced to choose between
>>>   1) no rewinding at all
>>>   2) imperfect rewinding in the sense that it sometimes can produce
>>> hearable artifacts
>>>
>>> ...I'm not sure 1) is always the right choice...
>>
>> Should we have a snd_pcm_open (or whatever else) flag for accepting
>> imperfect rewind results? [anyway, I would say "no" to using it in
>> PulseAudio]
>
> Well, if we had one, and it defaulted to the old behaviour, I suppose
> that would solve the new alsa-lib on old PA problem? But I'm not sure
> it's worth the added complexity.

Understood. Yes, it would solve the problem, and I have no opinion so 
far whether it is worth the cost of complexity and of the bad default.

This phrase from the documentation of snd_pcm_rewindable is also 
something to think about:

"""
Note: The snd_pcm_rewind() can accept bigger value than returned by this 
function. But it is not guaranteed that output stream will be consistent 
with bigger value.
"""

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Clemens Ladisch]

Alexander E. Patrakov wrote:
> |---------|---------P----h----p---------|-a-------|---------|
>
> So, what should alsa-lib return for snd_pcm_avail() and snd_pcm_rewind()?
> The driver only knows that "P" is already used, can infer that "p" isn't
> used yet, and knows nothing about samples in the middle.

Indeed.  However, the DMA pointer moves asynchronously, so it is possible
that it has already moved beyond p when snd_pcm_rewindable() returns.
For the samples between P and p, the risk is larger than for those after
p, but p is not a boundary where the risk abruptly decreases.

It would make sense to report the pointer update granularity, but not
to adjust the return value of snd_pcm_avail/rewindable().


Regards,
Clemens

Re: Master Plan on rewinding

[Clemens Ladisch]

Alexander E. Patrakov wrote:
> This phrase from the documentation of snd_pcm_rewindable is also
> something to think about:
>
> """
> Note: The snd_pcm_rewind() can accept bigger value than returned by
> this function. But it is not guaranteed that output stream will be
> consistent with bigger value.

This phrase again assumes a ring buffer, i.e., it says that
1) there is a buffer, and applications can write _anywhere_ in it, but
2) if a plugin reduces the allowed range (with snd_pcm_rewindable()),
   it is likely that the plugin will not notice that some part of the
   buffer has changed.

(The first part is not true for most unrewindable plugins.)


Regards,
Clemens

Re: Master Plan on rewinding

[Alexander E. Patrakov]

09.09.2014 14:43, Clemens Ladisch wrote:
> Alexander E. Patrakov wrote:
>> |---------|---------P----h----p---------|-a-------|---------|
>>
>> So, what should alsa-lib return for snd_pcm_avail() and snd_pcm_rewind()?
>> The driver only knows that "P" is already used, can infer that "p" isn't
>> used yet, and knows nothing about samples in the middle.
> Indeed.  However, the DMA pointer moves asynchronously, so it is possible
> that it has already moved beyond p when snd_pcm_rewindable() returns.
> For the samples between P and p, the risk is larger than for those after
> p, but p is not a boundary where the risk abruptly decreases.
>
> It would make sense to report the pointer update granularity, but not
> to adjust the return value of snd_pcm_avail/rewindable().

OK, I understand your viewpoint, and the phrase "some indicator of the 
actual rewind granularity and/or safeguard ... should be enough for PA 
to be able to pick a suitable default latency" from David indicates that 
he has a similar opinion.

Now the remaining question is: can the proposed heuristic (minimum 
period size for a given sample rate, number of channels and sample 
format) be useful as an upper-bound approximation of the pointer update 
granularity for cards that are "rewindable even further than the nearest 
period"?

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[David Henningsson]

On 2014-09-09 10:55, Alexander E. Patrakov wrote:
> 09.09.2014 14:43, Clemens Ladisch wrote:
>> Alexander E. Patrakov wrote:
>>> |---------|---------P----h----p---------|-a-------|---------|
>>>
>>> So, what should alsa-lib return for snd_pcm_avail() and
>>> snd_pcm_rewind()?
>>> The driver only knows that "P" is already used, can infer that "p" isn't
>>> used yet, and knows nothing about samples in the middle.
>> Indeed.  However, the DMA pointer moves asynchronously, so it is possible
>> that it has already moved beyond p when snd_pcm_rewindable() returns.
>> For the samples between P and p, the risk is larger than for those after
>> p, but p is not a boundary where the risk abruptly decreases.
>>
>> It would make sense to report the pointer update granularity, but not
>> to adjust the return value of snd_pcm_avail/rewindable().
>
> OK, I understand your viewpoint, and the phrase "some indicator of the
> actual rewind granularity and/or safeguard ... should be enough for PA
> to be able to pick a suitable default latency" from David indicates that
> he has a similar opinion.
>
> Now the remaining question is: can the proposed heuristic (minimum
> period size for a given sample rate, number of channels and sample
> format) be useful as an upper-bound approximation of the pointer update
> granularity for cards that are "rewindable even further than the nearest
> period"?

Aha, thanks for the explanation. Now I understand that approximation idea.
I don't know if that's a reasonable approximation, but even if it is, 
how would you determine if a card actually has that pointer granularity, 
or if the pointer granularity varies with period size? (I e without 
actually running a stream and measure it)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Master Plan on rewinding

[Alexander E. Patrakov]

09.09.2014 15:08, David Henningsson wrote:
>
>
> On 2014-09-09 10:55, Alexander E. Patrakov wrote:
>> 09.09.2014 14:43, Clemens Ladisch wrote:
>>> Alexander E. Patrakov wrote:
>>>> |---------|---------P----h----p---------|-a-------|---------|
>>>>
>>>> So, what should alsa-lib return for snd_pcm_avail() and
>>>> snd_pcm_rewind()?
>>>> The driver only knows that "P" is already used, can infer that "p"
>>>> isn't
>>>> used yet, and knows nothing about samples in the middle.
>>> Indeed.  However, the DMA pointer moves asynchronously, so it is
>>> possible
>>> that it has already moved beyond p when snd_pcm_rewindable() returns.
>>> For the samples between P and p, the risk is larger than for those after
>>> p, but p is not a boundary where the risk abruptly decreases.
>>>
>>> It would make sense to report the pointer update granularity, but not
>>> to adjust the return value of snd_pcm_avail/rewindable().
>>
>> OK, I understand your viewpoint, and the phrase "some indicator of the
>> actual rewind granularity and/or safeguard ... should be enough for PA
>> to be able to pick a suitable default latency" from David indicates that
>> he has a similar opinion.
>>
>> Now the remaining question is: can the proposed heuristic (minimum
>> period size for a given sample rate, number of channels and sample
>> format) be useful as an upper-bound approximation of the pointer update
>> granularity for cards that are "rewindable even further than the nearest
>> period"?
>
> Aha, thanks for the explanation. Now I understand that approximation idea.
> I don't know if that's a reasonable approximation, but even if it is,
> how would you determine if a card actually has that pointer granularity,
> or if the pointer granularity varies with period size? (I e without
> actually running a stream and measure it)

Currently, as you have already said, we have no such information. This 
information is, however, static for a given card model and should, in 
the future, come from the kernel. Therefore:

1. We need a new flag alongside SNDRV_PCM_INFO_BATCH that kernel drivers 
would set, and alsa-lib to act upon. As indicated in the following 
posts, SNDRV_PCM_INFO_BATCH means a different and not-useful-here thing:

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073817.html

2. We need a volunteer to crawl through kernel sources and mark drivers 
that cannot report the pointer position with a better-than-one-period 
granularity.

3. Until this is done, we have to either assume that all cards are good, 
or that all cards are bad, or maybe misuse the SNDRV_PCM_INFO_BATCH flag 
as a pessimistic approximation of what we want (and document this 
approximation) if anyone thinks that such misuse will be beneficial in 
the short term.

This leaves the question of "old kernel + new alsa-lib" open.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Clemens Ladisch]

Alexander E. Patrakov wrote:
> can the proposed heuristic (minimum period size for a given sample
> rate, number of channels and sample format) be useful as an upper-
> bound approximation of the pointer update granularity for cards that
> are "rewindable even further than the nearest period"?

No; USB precsion depends on the URB size, which is roughly proportional
to (but smaller than) the period size.


Regards,
Clemens

Re: Master Plan on rewinding

[Alexander E. Patrakov]

09.09.2014 19:45, Clemens Ladisch wrote:
> Alexander E. Patrakov wrote:
>> can the proposed heuristic (minimum period size for a given sample
>> rate, number of channels and sample format) be useful as an upper-
>> bound approximation of the pointer update granularity for cards that
>> are "rewindable even further than the nearest period"?
>
> No; USB precsion depends on the URB size, which is roughly proportional
> to (but smaller than) the period size.

Thanks for the explanation. It was very useful.

At this point, I am tempted to not express this "less than the period 
size but depends on it" rule, and classify USB audio devices as 
"Rewindable down to the period size", even though it is a pessimization.

Also (sorry for the off-topic) this explanation completely crystallizes 
my opinion about possible misuse of the SNDRV_PCM_INFO_BATCH flag in the 
snd-usb-audio driver or PulseAudio. My opinion now is: there is no 
misuse on either side.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Takashi Iwai]

At Tue, 09 Sep 2014 21:55:05 +0600,
Alexander E. Patrakov wrote:
> 
> 09.09.2014 19:45, Clemens Ladisch wrote:
> > Alexander E. Patrakov wrote:
> >> can the proposed heuristic (minimum period size for a given sample
> >> rate, number of channels and sample format) be useful as an upper-
> >> bound approximation of the pointer update granularity for cards that
> >> are "rewindable even further than the nearest period"?
> >
> > No; USB precsion depends on the URB size, which is roughly proportional
> > to (but smaller than) the period size.
> 
> Thanks for the explanation. It was very useful.
> 
> At this point, I am tempted to not express this "less than the period 
> size but depends on it" rule, and classify USB audio devices as 
> "Rewindable down to the period size", even though it is a pessimization.
> 
> Also (sorry for the off-topic) this explanation completely crystallizes 
> my opinion about possible misuse of the SNDRV_PCM_INFO_BATCH flag in the 
> snd-usb-audio driver or PulseAudio. My opinion now is: there is no 
> misuse on either side.

Well, it's not entirely a "misuse" in either side.  The flag is merely
a hint, and the current attitude of PA is in a safer side of the
behavior this flag may indicate.  Whether it's the best choice is
another question, of course.

After all, we certainly need some API to expose the granularity.  This
has been asked since long time ago, but it wasn't done simply because
the demands (and specifications) haven't been clarified.

Also, for rewinding, we may need to consider about the FIFO or other
things on top of signal processing path.  If the granularity defines
the granularity of the hwptr *update*, it wouldn't be enough for
defining a safe guard range.  Currently, most of hardware have a small
amount of FIFO that can be mostly ignored, fortunately, though.


Takashi

Re: Master Plan on rewinding

[Pierre-Louis Bossart]

>> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames -
>> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is
>> needed due to reasons that I don't completely understand, but one of
>> them is imprecise reporting of the hardware pointer, and another one is
>> that the hardware transfers several bytes at a time, and the bytes we
>> need to overwrite may be already cached by the hardware.
>
> Pierre added the rewind safeguard due to DMA controller problems. IIRC,
> some DMA controllers go nuts (such as breaking the stream, causing
> interrupt storms, or something else seriously buggy) when trying to
> write to data that the DMA controller is just about to transfer. Pierre
> (now cc:ed) would know more about this than I do, though.
>
> In my world, since this is a very hardware near problem, ALSA rather
> than PulseAudio should take these kinds of problems into account when
> reporting back snd_pcm_rewindable() so PulseAudio does not have to.


Sorry to chime-in late on this, my real job keeps me busy.
I would like to highlight that there is a fundamental conflict between 
requirements here.
- for power consumption optimization, you want to let the hardware 
prefetch audio samples opportunistically and buffer as much as possible 
as close as possible to the serial link. Given the pressure on power 
optimizations these days, no one should expect the hardware buffering to 
reduce - and this buffering could vary depending on the platform power 
modes with the position of the DMA read pointer becoming less predictable.
- for low-latency and user interaction, you want to rewind the write 
pointer as much as possible.

The question is 'how much'. The reason why i introduced this 
'rewind_safeguard' was to factor in a good-enough latency that no one 
would ever complain about and yet large enough to avoid using stale data.
We could ask drivers to provide a conservative estimate of this 
safeguard, but asking for a dynamic query of a safe position or an 
empirical determination based on the min period size is really asking 
for trouble. At a given point, if you really need very low-latency, i.e. 
sub ms, you will need a dedicated configuration that probably doesn't 
rely on rewinds and you probably don't use PulseAudio in the first place.

Re: Master Plan on rewinding

[Alexander E. Patrakov]

10.09.2014 01:56, Pierre-Louis Bossart wrote:
>
>>> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames -
>>> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is
>>> needed due to reasons that I don't completely understand, but one of
>>> them is imprecise reporting of the hardware pointer, and another one is
>>> that the hardware transfers several bytes at a time, and the bytes we
>>> need to overwrite may be already cached by the hardware.
>>
>> Pierre added the rewind safeguard due to DMA controller problems. IIRC,
>> some DMA controllers go nuts (such as breaking the stream, causing
>> interrupt storms, or something else seriously buggy) when trying to
>> write to data that the DMA controller is just about to transfer. Pierre
>> (now cc:ed) would know more about this than I do, though.
>>
>> In my world, since this is a very hardware near problem, ALSA rather
>> than PulseAudio should take these kinds of problems into account when
>> reporting back snd_pcm_rewindable() so PulseAudio does not have to.
>
>
> Sorry to chime-in late on this, my real job keeps me busy.

Better late than never.

> I would like to highlight that there is a fundamental conflict between
> requirements here.
> - for power consumption optimization, you want to let the hardware
> prefetch audio samples opportunistically and buffer as much as possible
> as close as possible to the serial link. Given the pressure on power
> optimizations these days, no one should expect the hardware buffering to
> reduce - and this buffering could vary depending on the platform power
> modes with the position of the DMA read pointer becoming less predictable.
> - for low-latency and user interaction, you want to rewind the write
> pointer as much as possible.

Spot-on.

> The question is 'how much'. The reason why i introduced this
> 'rewind_safeguard' was to factor in a good-enough latency that no one
> would ever complain about and yet large enough to avoid using stale data.
> We could ask drivers to provide a conservative estimate of this
> safeguard, but asking for a dynamic query of a safe position or an
> empirical determination based on the min period size is really asking
> for trouble. At a given point, if you really need very low-latency, i.e.
> sub ms, you will need a dedicated configuration that probably doesn't
> rely on rewinds and you probably don't use PulseAudio in the first place.

Well, now there are two people criticizing the heuristic. I would like 
to retract it, but I currently can't, because there are no other 
constructive proposals.

The best solution would indeed be if a driver provides a conservative 
estimate of the rewind safeguard, but the problem is that nobody will 
add this to old drivers for no-longer-manufactured hardware. So we 
either need some other heuristic here, or we have to allow rewinding 
further than the nearest period only on cards where drivers explicitly 
say OK by providing a safeguard value. But the later proposal kills 
power-efficient PulseAudio on old kernels that simply don't know how to 
provide this information. Surely you won't like it.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Raymond Yau]

>
> On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo,
the granularity is 32 bytes (= 8 samples), and I get the pointer
granularity of 64 bytes (=16 samples) over HDMI. The minimum period size is
32 samples in both cases.

Do you mean hda-Intel does not support arbritray period size when you say
the granularity is 32 bytes ?

However the granularity of the emulated hda sound card inside any VM depend
on the vm and the backend audio system and sound card

Re: Master Plan on rewinding

[A. C. Censi]

> However the granularity of the emulated hda sound card inside any VM
depend on the vm and the backend audio system and sound card

Obviously it is a "virtual granularity".

ACC
On Sep 11, 2014 12:49 AM, "Raymond Yau" <superquad.vortex2@gmail.com> wrote:

> >
> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo,
> the granularity is 32 bytes (= 8 samples), and I get the pointer
> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size is
> 32 samples in both cases.
>
> Do you mean hda-Intel does not support arbritray period size when you say
> the granularity is 32 bytes ?
>
> However the granularity of the emulated hda sound card inside any VM depend
> on the vm and the backend audio system and sound card
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: Master Plan on rewinding

[Alexander E. Patrakov]

11.09.2014 09:49, Raymond Yau wrote:
>
>  >
>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer
> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size
> is 32 samples in both cases.
>
> Do you mean hda-Intel does not support arbritray period size when you
> say the granularity is 32 bytes ?
>
> However the granularity of the emulated hda sound card inside any VM
> depend on the vm and the backend audio system and sound card

The precise meaning is defined here:

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html

Of course the VM result would be different.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Raymond Yau]

2014-9-11 下午1:28 於 "Alexander E. Patrakov" <patrakov@gmail.com> 寫道：
>
> 11.09.2014 09:49, Raymond Yau wrote:
>>
>>
>>  >
>>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
>> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer
>> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size
>> is 32 samples in both cases.
>>
>> Do you mean hda-Intel does not support arbritray period size when you
>> say the granularity is 32 bytes ?
>>
>> However the granularity of the emulated hda sound card inside any VM
>> depend on the vm and the backend audio system and sound card
>
>
> The precise meaning is defined here:
>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html

>
> Of course the VM result would be different.
>
> -

http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/plain/hw/hda-audio.c

/* audio in/out widget */
    case AC_VERB_SET_CHANNEL_STREAMID:
        st = a->st + node->stindex;
        if (st->node == NULL) {
            goto fail;
        }
        hda_audio_set_running(st, false);
        st->stream = (payload >> 4) & 0x0f;
        st->channel = payload & 0x0f;
        dprint(a, 2, "%s: stream %d, channel %d\n",
               st->node->name, st->stream, st->channel);
        hda_audio_set_running(st, a->running_real[st->output * 16 +
st->stream]);
        hda_codec_response(hda, true, 0);
        break;

It seem some vm just emulate start/stop of playback/capture  , it does not
update any hda controller registers, this mean that it won't support rewind
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Master Plan on rewinding

[Raymond Yau]

>>
>>  >
>>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
>> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer
>> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size
>> is 32 samples in both cases.
>>
>> Do you mean hda-Intel does not support arbritray period size when you
>> say the granularity is 32 bytes ?
>>
>> However the granularity of the emulated hda sound card inside any VM
>> depend on the vm and the backend audio system and sound card
>
>
> The precise meaning is defined here:
>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html

Do you mean the different hda controllers may have different granularity ?

Do your two hda controllers have different Fifo size ?

Re: Master Plan on rewinding

[Raymond Yau]

>
> > However the granularity of the emulated hda sound card inside any VM
depend on the vm and the backend audio system and sound card
>
> Obviously it is a "virtual granularity".
>

Seem emulate dma transfer

http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/plain/hw/intel-hda.c

But not all backend can provide same granularity

http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/tree/audio

Re: Master Plan on rewinding

[Alexander E. Patrakov]

13.09.2014 14:57, Raymond Yau wrote:
>
>  >>
>  >>  >
>  >>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
>  >> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer
>  >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size
>  >> is 32 samples in both cases.
>  >>
>  >> Do you mean hda-Intel does not support arbritray period size when you
>  >> say the granularity is 32 bytes ?
>  >>
>  >> However the granularity of the emulated hda sound card inside any VM
>  >> depend on the vm and the backend audio system and sound card
>  >
>  >
>  > The precise meaning is defined here:
>  >
>  > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html
>
> Do you mean the different hda controllers may have different granularity ?

Yes. My two hda controllers have different granularity.

> Do your two hda controllers have different Fifo size ?

If you mean the result of snd_pcm_hw_params_get_fifo_size(), then both 
cards return 0. I call this function after snd_pcm_hw_params(), as 
recommended by the documentation.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Raymond Yau]

2014-9-13 下午6:43 於 "Alexander E. Patrakov" <patrakov@gmail.com> 寫道：
>
> 13.09.2014 14:57, Raymond Yau wrote:
>>
>>
>>  >>
>>  >>  >
>>  >>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
>>  >> stereo, the granularity is 32 bytes (= 8 samples), and I get the
pointer
>>  >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period
size
>>  >> is 32 samples in both cases.
>>  >>
>>  >> Do you mean hda-Intel does not support arbritray period size when you
>>  >> say the granularity is 32 bytes ?
>>  >>
>>  >> However the granularity of the emulated hda sound card inside any VM
>>  >> depend on the vm and the backend audio system and sound card
>>  >
>>  >
>>  > The precise meaning is defined here:
>>  >
>>  >
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html
>>
>> Do you mean the different hda controllers may have different granularity
?
>
>
> Yes. My two hda controllers have different granularity.
>
>
>> Do your two hda controllers have different Fifo size ?
>
>
> If you mean the result of snd_pcm_hw_params_get_fifo_size(), then both
cards return 0. I call this function after snd_pcm_hw_params(), as
recommended by the documentation.

Do your hda controllers OSDnFIFOS register match the granularity ?

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

Length: 2 bytes

Table 39. Stream Descriptor n FIFO Size Bit Type Reset Description 15:0 RO
Imp.Dep

FIFO Size (FIFOS):  Indicates the maximum number of bytes that could be
fetched by the controller at one time.  This is the maximum number of bytes
that may have been DMA‟d into memory but not yet transmitted on the link,
and is also the maximum possible value that the LPIB count will increase by
at one time.  This number may be static to indicate a static buffer size,
or may change after the data format has been programmed if the controller
is able to vary its FIFO size based on the stream format.  If it is able to
change value after the data format has been programmed, the value update
must happen immediately before the next read of the FIFOS register, and
remain static until the next programming of data format.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Master Plan on rewinding

[Alexander E. Patrakov]

13.09.2014 17:33, Raymond Yau wrote:
>
> 2014-9-13 下午6:43 於 "Alexander E. Patrakov" <patrakov@gmail.com
> <mailto:patrakov@gmail.com>> 寫道：
>  >
>  > 13.09.2014 14:57, Raymond Yau wrote:
>  >>
>  >>
>  >>  >>
>  >>  >>  >
>  >>  >>  > On my desktop PC, on snd-hda-intel with analog outputs for S16LE
>  >>  >> stereo, the granularity is 32 bytes (= 8 samples), and I get the
> pointer
>  >>  >> granularity of 64 bytes (=16 samples) over HDMI. The minimum
> period size
>  >>  >> is 32 samples in both cases.
>  >>  >>
>  >>  >> Do you mean hda-Intel does not support arbritray period size
> when you
>  >>  >> say the granularity is 32 bytes ?
>  >>  >>
>  >>  >> However the granularity of the emulated hda sound card inside any VM
>  >>  >> depend on the vm and the backend audio system and sound card
>  >>  >
>  >>  >
>  >>  > The precise meaning is defined here:
>  >>  >
>  >>  >
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html
>  >>
>  >> Do you mean the different hda controllers may have different
> granularity ?
>  >
>  >
>  > Yes. My two hda controllers have different granularity.
>  >
>  >
>  >> Do your two hda controllers have different Fifo size ?
>  >
>  >
>  > If you mean the result of snd_pcm_hw_params_get_fifo_size(), then
> both cards return 0. I call this function after snd_pcm_hw_params(), as
> recommended by the documentation.
>
> Do your hda controllers OSDnFIFOS register match the granularity ?

I don't know. Please send a program or a kernel patch that prints this 
value (including units - samples or bytes), otherwise I won't be able to 
answer.

-- 
Alexander E. Patrakov
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Master Plan on rewinding

[Alexander E. Patrakov]

07.09.2014 21:16, Alexander E. Patrakov wrote:
> 1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA
> plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28,
> but in some cases snd_pcm_rewindable() still returns wrong results.

Bad news: even in 1.0.28, snd_pcm_rewindable() crashes for the file 
plugin due to recursion. So I was wrong when saying "fixed completely" :(

> 3. On the hw plugin, I could demonstrate two other bugs regarding
> snd_pcm_rewindable(): stale data and bogus negative return values.

For all of the above issues, I have sent patches.

> === On the rewind safeguard ===

Result 1: it has been decided that the return value of 
snd_pcm_rewindable() is not changed, and the safeguard is returned by a 
separate function. This would require documentation changes for 
snd_pcm_rewindable(), though, as it officially no longer returns "safe 
count of frames which can be rewinded". I have difficulty designing a 
better wording what the function actually means now.

Result 2: the proposed heuristic has been rightfully and convincingly 
busted, but no alternatives were proposed. It is the top priority to get 
some constructive proposal here where to get the data, or a fallback 
plan for alsa-lib. A fallback plan is also needed for old kernels if the 
constructive proposal involves kernel changes.

> === On non-rewindability of the rate plugin ===

Nothing more to discuss.

> === On possibly-incomplete rewindability of the file plugin ===

Nothing more to discuss.

> === On bogus rewindability of ladspa and extplug plugins ===

No conclusion. The proposed hack to leave the .rewind implementation in 
place for use by old PulseAudio has met some opposition, but not such 
definite and convincing opposition as to the rewind-safeguard and 
low-latency-thread proposals. The proposed alternative (to make a 
"disallow imperfect rewinds" flag, off by default) means more work for 
no gain, and David also doubts whether such flag is worth the 
complexity. It's also notable that nobody explicitly said "let's regress 
old pulseaudio on new alsa-lib on the obscure dca plugin in the name of 
clean code" - which would have also closed the question :)

In fact, I am not really sure that everyone understands the problem.

> === On bogus rewindability of some ioplug-based plugins ===

The "low-latency-thread in ioplug" idea has been rightfully busted, and 
transformed into the "flexiblerewind" plugin idea. However, that plugin 
found no users (as PulseAudio won't use it), and thus there is no 
incentive for me or anyone else to implement it. Nothing left to discuss.

> === On the pulse plugin ===

We have reached an agreement that .rewindable and .rewind should be 
added to ioplug and used by the pulse plugin. Nothing more to discuss.

> === On communication of non-rewindability to the program ===

We have very good progress here: recognition of three rewindability 
classes that seemingly nobody objects to. The wanted behavior of 
PulseAudio for each rewindability class is not something we currently 
fully agree upon, though, but I think that it will be more appropriate 
to discuss further when someone sends a PulseAudio patch making use of 
these classes. I.e. not now. It is very good that there is at least one 
more person (Pierre Bossart) who understands the inherent conflict of 
requirements.

Transition plan remains to be discussed, but that's the same discussion 
as the one called for in the "rewind safeguard" part of the post.

> === On the programmer expectations ===
>
> (social issue)

Resolved (was misinterpretation on my side). I have to submit the 
documentation patch.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Raymond Yau]

>
>
>> === On the rewind safeguard ===
>
>
> Result 1: it has been decided that the return value of
snd_pcm_rewindable() is not changed, and the safeguard is returned by a
separate function.

It is unlikely to return any value which is safe, it is the responsiability
of the application to decide how much can be rewind

If pulseaudio assume 20ms process time is require to process two seconds of
audio and sleep for 1980ms, it should not assume cpu have infinite power

what is the purpose of the timestamp ?

Can the timestamp use to predict when will next period update occur if the
timestamp is obtained at previous period update ?

Why snd_pcm_rewind cannot return error when application  just set stop
threshold to buffer size and rewind more than the stop threshold ?

:This would require documentation changes for snd_pcm_rewindable(), though,
as it officially no longer returns "safe count of frames which can be
rewinded". I have difficulty designing a better wording what the function
actually means now.

The word "safe" should be removed

Re: Master Plan on rewinding

[Alexander E. Patrakov]

14.09.2014 17:37, Raymond Yau wrote:
>
>  >
>  >
>  >> === On the rewind safeguard ===
>  >
>  >
>  > Result 1: it has been decided that the return value of
> snd_pcm_rewindable() is not changed, and the safeguard is returned by a
> separate function.
>
> It is unlikely to return any value which is safe, it is the
> responsiability of the application to decide how much can be rewind

You are placing a responsibility on an application without giving it any 
means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, 
but definitely not OK on ymfpci even on infinitely fast CPU (because of 
the fixed 5 ms interrupt interval). The whole question here is: how is 
an application supposed to know that?

>
> If pulseaudio assume 20ms process time is require to process two seconds
> of audio and sleep for 1980ms, it should not assume cpu have infinite power

You are right. The safeguard interval is a sum of the CPU-independent 
but card-specific part (which is what is being talked about) and a 
CPU-specific part (which the application indeed should know).

>
> what is the purpose of the timestamp ?
>
> Can the timestamp use to predict when will next period update occur if
> the timestamp is obtained at previous period update ?

See http://0pointer.de/blog/projects/pulse-glitch-free.html

>
> Why snd_pcm_rewind cannot return error when application  just set stop
> threshold to buffer size and rewind more than the stop threshold ?

I think it does. The problem (due to which we need a safeguard) is that 
the card-specific minimum number of not-really-rewindable samples 
exists. E.g., for ymfpci, that would be 5 ms.

>
> :This would require documentation changes for snd_pcm_rewindable(),
> though, as it officially no longer returns "safe count of frames which
> can be rewinded". I have difficulty designing a better wording what the
> function actually means now.
>
> The word "safe" should be removed

That's insufficient. The returned value is valid only in the ring-buffer 
model for a card that fetches samples absolutely uniformly one at a 
time, i.e. without any batching, updates the pointer at every 
played-back sample, and doesn't have any "don't overwrite what I am 
DMA-ing or I will kill you with IRQs" quirk. I.e., even with the 
infinitely fast CPU, an attempt to rewind as much as that function 
returns (and then overwrite) will yield a glitch (that may or may not be 
detected as xrun even if xrun detection is enabled).

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Raymond Yau]

>>  >
>>  >> === On the rewind safeguard ===
>>  >
>>  >
>>  > Result 1: it has been decided that the return value of
>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a
>> separate function.
>>
>> It is unlikely to return any value which is safe, it is the
>> responsiability of the application to decide how much can be rewind
>
>
> You are placing a responsibility on an application without giving it any
means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, but
definitely not OK on ymfpci even on infinitely fast CPU (because of the
fixed 5 ms interrupt interval). The whole question here is: how is an
application supposed to know that?
>

Take a look at patent US 20100131783

System and Method of Dynamically Switching Queue Threshold

HDA may have different fifo threshold in different power states, the
granularity is not fixed

Twice the minimum period size/time is not any over estimate

Glitching still occurs at switch sink / change in power state when  you
allow sound card run with lowest latency ?

I don't think your proposal of having three different class of granularity
is good idea

Re: Master Plan on rewinding

[Takashi Iwai]

At Sun, 14 Sep 2014 18:07:23 +0600,
Alexander E. Patrakov wrote:
> 
> 14.09.2014 17:37, Raymond Yau wrote:
> >
> >  >
> >  >
> >  >> === On the rewind safeguard ===
> >  >
> >  >
> >  > Result 1: it has been decided that the return value of
> > snd_pcm_rewindable() is not changed, and the safeguard is returned by a
> > separate function.
> >
> > It is unlikely to return any value which is safe, it is the
> > responsiability of the application to decide how much can be rewind
> 
> You are placing a responsibility on an application without giving it any 
> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, 
> but definitely not OK on ymfpci even on infinitely fast CPU (because of 
> the fixed 5 ms interrupt interval). The whole question here is: how is 
> an application supposed to know that?

Well, maybe the word "safeguard" is somewhat confusing to be used as
a driver API.  There is no "safety" at all there.  There is only
"theoretically minimal" (and it often lies even if the hardware chip
says so).  How much value to be taken as "safeguard" is rather a
choice by each application or sound backend.

Right now, the only information we give from the sound driver is
INFO_BATCH flag.  And I agree with a bit more detailed information to
be exposed from the driver -- but only if possible.  This must be an
optional information and not mandatory.


Takashi

Re: Master Plan on rewinding

[Alexander E. Patrakov]

15.09.2014 15:19, Takashi Iwai wrote:
> At Sun, 14 Sep 2014 18:07:23 +0600,
> Alexander E. Patrakov wrote:
>>
>> 14.09.2014 17:37, Raymond Yau wrote:
>>>
>>>   >
>>>   >
>>>   >> === On the rewind safeguard ===
>>>   >
>>>   >
>>>   > Result 1: it has been decided that the return value of
>>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a
>>> separate function.
>>>
>>> It is unlikely to return any value which is safe, it is the
>>> responsiability of the application to decide how much can be rewind
>>
>> You are placing a responsibility on an application without giving it any
>> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel,
>> but definitely not OK on ymfpci even on infinitely fast CPU (because of
>> the fixed 5 ms interrupt interval). The whole question here is: how is
>> an application supposed to know that?
>
> Well, maybe the word "safeguard" is somewhat confusing to be used as
> a driver API.  There is no "safety" at all there.  There is only
> "theoretically minimal" (and it often lies even if the hardware chip
> says so).  How much value to be taken as "safeguard" is rather a
> choice by each application or sound backend.

I agree with this "bad wording" remark. Let's talk about the 
"theoretically minimal non-rewindable amount of samples" from now on.

> Right now, the only information we give from the sound driver is
> INFO_BATCH flag.  And I agree with a bit more detailed information to
> be exposed from the driver -- but only if possible.  This must be an
> optional information and not mandatory.

Here I mostly agree.

Indeed, this INFO_BATCH flag exists. However, its documentation is so 
vague that IMHO a documentation patch is needed to legitimize its use as 
a "you must not leave less than one period when rewinding" indicator. 
Also, the documentation says about snd_pcm_hw_params_is_batch(): "This 
function should only be called when the configuration space contains a 
single configuration" - I believe that it is an error (and PulseAudio 
calls it without obeying this restriction), because this function is 
helpful exactly for choosing hardware parameters such as period size. 
May I write "if the configuration space contains more than one 
configuration, the result indicates whether a configuration exists where 
such double-buffering is done"? Also the documentation talks about 
"hardware", should I extend it to the whole plugin chain?

As for the desire to export other information if available, it is 
certainly good.

What remains not fully understood for me is the claim that the 
information already exposed by every driver (in the form of the minimal 
period size) is not useful. I understand that two people are against 
this idea, so it must be bad. But I must understand why. Is it because 
the minimum period size reported by some drivers (which ones are 
suspected, if any?) may be a lie?

Clemens Ladisch mentioned USB as a counterexample, but it is a batch 
device for which the current period size is more relevant than the 
minimal one. Pierre-Louis Bossart just said that it is "really asking 
for trouble" without much explanation.

Can anyone name a sound controller that is not of a batch variety, where 
the theoretically minimal non-rewindable amount of samples is, at some 
settings, higher than the reported minimum period size at the same 
number of channels, sample rate and sample format?

[and yes, I understand that I can always cheat and say: let's change the 
definition of INFO_BATCH so that it includes such cases]

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Takashi Iwai]

At Mon, 15 Sep 2014 15:58:42 +0600,
Alexander E. Patrakov wrote:
> 
> 15.09.2014 15:19, Takashi Iwai wrote:
> > At Sun, 14 Sep 2014 18:07:23 +0600,
> > Alexander E. Patrakov wrote:
> >>
> >> 14.09.2014 17:37, Raymond Yau wrote:
> >>>
> >>>   >
> >>>   >
> >>>   >> === On the rewind safeguard ===
> >>>   >
> >>>   >
> >>>   > Result 1: it has been decided that the return value of
> >>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a
> >>> separate function.
> >>>
> >>> It is unlikely to return any value which is safe, it is the
> >>> responsiability of the application to decide how much can be rewind
> >>
> >> You are placing a responsibility on an application without giving it any
> >> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel,
> >> but definitely not OK on ymfpci even on infinitely fast CPU (because of
> >> the fixed 5 ms interrupt interval). The whole question here is: how is
> >> an application supposed to know that?
> >
> > Well, maybe the word "safeguard" is somewhat confusing to be used as
> > a driver API.  There is no "safety" at all there.  There is only
> > "theoretically minimal" (and it often lies even if the hardware chip
> > says so).  How much value to be taken as "safeguard" is rather a
> > choice by each application or sound backend.
> 
> I agree with this "bad wording" remark. Let's talk about the 
> "theoretically minimal non-rewindable amount of samples" from now on.
> 
> > Right now, the only information we give from the sound driver is
> > INFO_BATCH flag.  And I agree with a bit more detailed information to
> > be exposed from the driver -- but only if possible.  This must be an
> > optional information and not mandatory.
> 
> Here I mostly agree.
> 
> Indeed, this INFO_BATCH flag exists. However, its documentation is so 
> vague that IMHO a documentation patch is needed to legitimize its use as 
> a "you must not leave less than one period when rewinding" indicator. 
> Also, the documentation says about snd_pcm_hw_params_is_batch(): "This 
> function should only be called when the configuration space contains a 
> single configuration" - I believe that it is an error (and PulseAudio 
> calls it without obeying this restriction), because this function is 
> helpful exactly for choosing hardware parameters such as period size. 
> May I write "if the configuration space contains more than one 
> configuration, the result indicates whether a configuration exists where 
> such double-buffering is done"? Also the documentation talks about 
> "hardware", should I extend it to the whole plugin chain?

The whole hw_params_*() descriptions are something like bot-style
tweets, we need a bit better texts there :)

The batch parameter was (and partly is) indeed very ambiguous.  Its
usage has been materialized a few years ago.

> As for the desire to export other information if available, it is 
> certainly good.
> 
> What remains not fully understood for me is the claim that the 
> information already exposed by every driver (in the form of the minimal 
> period size) is not useful. I understand that two people are against 
> this idea, so it must be bad. But I must understand why. Is it because 
> the minimum period size reported by some drivers (which ones are 
> suspected, if any?) may be a lie?

A kind of yes.  Many drivers, especially the old ones, set the minimal
period size without actually knowing the real limit.  It tends to be
smaller than the hardware really supports.  This is, in most cases, 
just because no hardware spec defines that.  So, it can't be blindly
taken as the bottom line, unfortunately.  That's why I suggested the
new field would be optional; we simply don't know the value.


Takashi

> Clemens Ladisch mentioned USB as a counterexample, but it is a batch 
> device for which the current period size is more relevant than the 
> minimal one. Pierre-Louis Bossart just said that it is "really asking 
> for trouble" without much explanation.
> 
> Can anyone name a sound controller that is not of a batch variety, where 
> the theoretically minimal non-rewindable amount of samples is, at some 
> settings, higher than the reported minimum period size at the same 
> number of channels, sample rate and sample format?
> 
> [and yes, I understand that I can always cheat and say: let's change the 
> definition of INFO_BATCH so that it includes such cases]
> 
> -- 
> Alexander E. Patrakov
> 

Re: Master Plan on rewinding

[Pierre-Louis Bossart]

>> What remains not fully understood for me is the claim that the
>> information already exposed by every driver (in the form of the minimal
>> period size) is not useful. I understand that two people are against
>> this idea, so it must be bad. But I must understand why. Is it because
>> the minimum period size reported by some drivers (which ones are
>> suspected, if any?) may be a lie?
>
> A kind of yes.  Many drivers, especially the old ones, set the minimal
> period size without actually knowing the real limit.  It tends to be
> smaller than the hardware really supports.  This is, in most cases,
> just because no hardware spec defines that.  So, it can't be blindly
> taken as the bottom line, unfortunately.  That's why I suggested the
> new field would be optional; we simply don't know the value.

Agree with Takashi, even recent audio IP tend to be reused in various 
ways (buses, system agents, arbiters, DMA controllers, DDR controllers) 
and no one really knows what the rewind granularity is, it's not a 
metric that's tracked.

I actually liked the heuristic that's present in PulseAudio: constrain 
the safeguard to 256 bytes or 1ms (the last part would actually be 
fixed, it's currently not dependent on the sink actual rate and number 
of channels). we could introduce an optional query drivers for this but 
I wonder if it's worth the effort.
-Pierre

Re: Master Plan on rewinding

[Alexander E. Patrakov]

15.09.2014 23:01, Pierre-Louis Bossart wrote:
>
>>> What remains not fully understood for me is the claim that the
>>> information already exposed by every driver (in the form of the minimal
>>> period size) is not useful. I understand that two people are against
>>> this idea, so it must be bad. But I must understand why. Is it because
>>> the minimum period size reported by some drivers (which ones are
>>> suspected, if any?) may be a lie?
>>
>> A kind of yes.  Many drivers, especially the old ones, set the minimal
>> period size without actually knowing the real limit.  It tends to be
>> smaller than the hardware really supports.  This is, in most cases,
>> just because no hardware spec defines that.  So, it can't be blindly
>> taken as the bottom line, unfortunately.  That's why I suggested the
>> new field would be optional; we simply don't know the value.
>
> Agree with Takashi, even recent audio IP tend to be reused in various
> ways (buses, system agents, arbiters, DMA controllers, DDR controllers)
> and no one really knows what the rewind granularity is, it's not a
> metric that's tracked.
>
> I actually liked the heuristic that's present in PulseAudio: constrain
> the safeguard to 256 bytes or 1ms (the last part would actually be
> fixed, it's currently not dependent on the sink actual rate and number
> of channels). we could introduce an optional query drivers for this but
> I wonder if it's worth the effort.

OK, a direct question then.

The "256 bytes or 1 ms" heuristic is known not to work on ymfpci. Should 
we bump it to "5.3 ms or 256 samples", or make configurable, or ask the 
ymfpci maintainer to add the INFO_BATCH flag to that driver?

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Takashi Iwai]

At Mon, 15 Sep 2014 23:14:41 +0600,
Alexander E. Patrakov wrote:
> 
> 15.09.2014 23:01, Pierre-Louis Bossart wrote:
> >
> >>> What remains not fully understood for me is the claim that the
> >>> information already exposed by every driver (in the form of the minimal
> >>> period size) is not useful. I understand that two people are against
> >>> this idea, so it must be bad. But I must understand why. Is it because
> >>> the minimum period size reported by some drivers (which ones are
> >>> suspected, if any?) may be a lie?
> >>
> >> A kind of yes.  Many drivers, especially the old ones, set the minimal
> >> period size without actually knowing the real limit.  It tends to be
> >> smaller than the hardware really supports.  This is, in most cases,
> >> just because no hardware spec defines that.  So, it can't be blindly
> >> taken as the bottom line, unfortunately.  That's why I suggested the
> >> new field would be optional; we simply don't know the value.
> >
> > Agree with Takashi, even recent audio IP tend to be reused in various
> > ways (buses, system agents, arbiters, DMA controllers, DDR controllers)
> > and no one really knows what the rewind granularity is, it's not a
> > metric that's tracked.
> >
> > I actually liked the heuristic that's present in PulseAudio: constrain
> > the safeguard to 256 bytes or 1ms (the last part would actually be
> > fixed, it's currently not dependent on the sink actual rate and number
> > of channels). we could introduce an optional query drivers for this but
> > I wonder if it's worth the effort.
> 
> OK, a direct question then.
> 
> The "256 bytes or 1 ms" heuristic is known not to work on ymfpci. Should 
> we bump it to "5.3 ms or 256 samples", or make configurable, or ask the 
> ymfpci maintainer to add the INFO_BATCH flag to that driver?

Adding INFO_BATCH would be a quick solution, indeed, although this
isn't 100% right.


Takashi

Re: Master Plan on rewinding

[Raymond Yau]

> > >
> > >>> What remains not fully understood for me is the claim that the
> > >>> information already exposed by every driver (in the form of the
minimal
> > >>> period size) is not useful. I understand that two people are against
> > >>> this idea, so it must be bad. But I must understand why. Is it
because
> > >>> the minimum period size reported by some drivers (which ones are
> > >>> suspected, if any?) may be a lie?

Does this mean the granularity of most drivers are only one period since
most of them cannot reporte the dma position in realtime  ?

(e.g. pointer callback of Intel8x0 use a timeout loop to read the last
valid index)

  The safeguard will be two periods

If some HDA have FIFO size of 192 bytes which is more than the minimum
period bytes

Should we limit the start threshold to FIFO threshold or FIFO size ?

Does it need Brust length = 1 for those hda controller to support arbitrary
period size ?

Seem only some hda controller can trigger DMA transfer at 1/3 or 2/3 FIFO
buffer at different power states and report the dma position in pointer
callback

Does snd-oxygen provide this position with granularity which is less than
the minimum period size ?

Re: Master Plan on rewinding

[Raymond Yau]

>>>>>
>>>>> |---------|---------P----h----p---------|-a-------|---------|
>>>>>
>>>>> So, what should alsa-lib return for snd_pcm_avail() and
>>>>> snd_pcm_rewind()?
>>>>> The driver only knows that "P" is already used, can infer that "p"
>>>>> isn't
>>>>> used yet, and knows nothing about samples in the middle.
>>>>
>>>> Indeed.  However, the DMA pointer moves asynchronously, so it is
>>>> possible
>>>> that it has already moved beyond p when snd_pcm_rewindable() returns.
>>>> For the samples between P and p, the risk is larger than for those
after
>>>> p, but p is not a boundary where the risk abruptly decreases.
>>>>
>>>> It would make sense to report the pointer update granularity, but not
>>>> to adjust the return value of snd_pcm_avail/rewindable().
>>>
>>>
>>> OK, I understand your viewpoint, and the phrase "some indicator of the
>>> actual rewind granularity and/or safeguard ... should be enough for PA
>>> to be able to pick a suitable default latency" from David indicates that
>>> he has a similar opinion.
>>>
>>> Now the remaining question is: can the proposed heuristic (minimum
>>> period size for a given sample rate, number of channels and sample
>>> format) be useful as an upper-bound approximation of the pointer update
>>> granularity for cards that are "rewindable even further than the nearest
>>> period"?
>>
>>
>> Aha, thanks for the explanation. Now I understand that approximation
idea.
>> I don't know if that's a reasonable approximation, but even if it is,
>> how would you determine if a card actually has that pointer granularity,
>> or if the pointer granularity varies with period size? (I e without
>> actually running a stream and measure it)
>
>
> Currently, as you have already said, we have no such information. This
information is, however, static for a given card model and should, in the
future, come from the kernel. Therefore:
>
> 1. We need a new flag alongside SNDRV_PCM_INFO_BATCH that kernel drivers
would set, and alsa-lib to act upon. As indicated in the following posts,
SNDRV_PCM_INFO_BATCH means a different and not-useful-here thing:
>
>
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html
>
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073817.html
>
> 2. We need a volunteer to crawl through kernel sources and mark drivers
that cannot report the pointer position with a better-than-one-period
granularity.
>
> 3. Until this is done, we have to either assume that all cards are good,
or that all cards are bad, or maybe misuse the SNDRV_PCM_INFO_BATCH flag as
a pessimistic approximation of what we want (and document this
approximation) if anyone thinks that such misuse will be beneficial in the
short term.
>
> This leaves the question of "old kernel + new alsa-lib" open.
>
> --

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc/soc-generic-dmaengine-pcm.c?id=478028e088d6a94666d8a776be2cd2291faf3bbd

a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse.
b) Fallback to the (race condition prone) period counting if the driver
does not support any residue reporting.

Seem soc already have this granularity

How can the granularity worse more than one period ?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h

enum dma_residue_granularity {
DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0,
DMA_RESIDUE_GRANULARITY_SEGMENT = 1,
DMA_RESIDUE_GRANULARITY_BURST = 2,
};

There are three type of granularity

Does this mean the those sound card can report
DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer callback ?

A few PCI sound cards use SG buffer including hda

It seem that pulseaudio expect the driver support
DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling

/**
* enum dma_residue_granularity - Granularity of the reported transfer
residue
* @DMA_RESIDUE_GRANULARITY_DESCRIPTOR: Residue reporting is not support.
The  DMA channel is only able to tell whether a descriptor has been
completed or not, which means residue reporting is not supported by this
channel. The residue field of the dma_tx_state field will always be 0.
* @DMA_RESIDUE_GRANULARITY_SEGMENT: Residue is updated after each
successfully completed segment of the transfer (For cyclic transfers this
is after each  period). This is typically implemented by having the
hardware generate an  interrupt after each transferred segment and then the
drivers updates the outstanding residue by the size of the segment. Another
possibility is if the hardware supports scatter-gather and the segment
descriptor has a field  which gets set after the segment has been
completed. The driver then counts the number of segments without the flag
set to compute the residue.
* @DMA_RESIDUE_GRANULARITY_BURST: Residue is updated after each transferred
burst. This is typically only supported if the hardware has a progress
register of some sort (E.g. a register with the current read/write address
or a register with the amount of bursts/beats/bytes that have been
transferred or still need to be transferred).
*/

Re: Master Plan on rewinding

[Alexander E. Patrakov]

18.09.2014 07:15, Raymond Yau wrote:
>
>  > > >
>  > > >>> What remains not fully understood for me is the claim that the
>  > > >>> information already exposed by every driver (in the form of the
> minimal
>  > > >>> period size) is not useful. I understand that two people are
> against
>  > > >>> this idea, so it must be bad. But I must understand why. Is it
> because
>  > > >>> the minimum period size reported by some drivers (which ones are
>  > > >>> suspected, if any?) may be a lie?
>
> Does this mean the granularity of most drivers are only one period since
> most of them cannot reporte the dma position in realtime  ?

I guess you are right.

>
> (e.g. pointer callback of Intel8x0 use a timeout loop to read the last
> valid index)
>
>    The safeguard will be two periods

Here I don't see how that can be right. Even if the position is updated 
at each period interrupt, we always know which period is currently 
playing. So the theoretical minimum safeguard is exactly one period. Add 
1 ms on top if you want to account for scheduler glitches.

>
> If some HDA have FIFO size of 192 bytes which is more than the minimum
> period bytes
>
> Should we limit the start threshold to FIFO threshold or FIFO size ?

I think that in this case it is a bug to report such small minimum 
period size.

> Does it need Brust length = 1 for those hda controller to support
> arbitrary period size ?
>
> Seem only some hda controller can trigger DMA transfer at 1/3 or 2/3
> FIFO buffer at different power states and report the dma position in
> pointer callback

I am not a specialist in HDA hardware.

> Does snd-oxygen provide this position with granularity which is less
> than the minimum period size ?

I have a friend with a Xonar card, will ask him to perform a test for 
you when he appears online.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Clemens Ladisch]

Raymond Yau wrote:
> Does snd-oxygen provide this position with granularity which is less than
> the minimum period size ?

Yes.  Its DMA controller uses a burst size of 32 bytes.  The pointer registers
are documented as reporting the position with 4-byte accuracy, but there were
problems when the period/buffer sizes were not aligned to 32 bytes.  I've set
the minimum period size to 64 bytes, just to be safe.


Regards,
Clemens

Re: Master Plan on rewinding

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

21.09.2014 15:53, Clemens Ladisch wrote:
> Raymond Yau wrote:
>> Does snd-oxygen provide this position with granularity which is less than
>> the minimum period size ?
>
> Yes.  Its DMA controller uses a burst size of 32 bytes.  The pointer registers
> are documented as reporting the position with 4-byte accuracy, but there were
> problems when the period/buffer sizes were not aligned to 32 bytes.  I've set
> the minimum period size to 64 bytes, just to be safe.

Well, my friend has tested the card anyway, and I am afraid that the 
situation is in fact more complex than documented. Look how fast (8 
samples per ioctl in a busy loop!) the card eats the first 256 samples. 
This is very suspicious, and I am not really sure whether we can 
actually perform a rewind over these 256 samples.

The "usual" step of the pointer updates (via snd_pcm_avail) is indeed 8 
samples = 32 bytes with some fine-grained updates sometimes showing up 
in the middle, which matches the documented burst size.

-- 
Alexander E. Patrakov

[-- Attachment #2: pcm_avail.c --]
[-- Type: text/x-csrc, Size: 3669 bytes --]

/*
 *  This extra small demo sends silence to your speakers and tests the precision of the reported position.
 */

#include <asoundlib.h>

#include <stdio.h>
#include <stdlib.h>

const char* device = "hw:0";
const int channels = 2;
const snd_pcm_sframes_t period_size = 1024;
const int periods = 4;
const int rate = 48000;


int main(int argc, char* argv[])
{
        int err;
	int failed = 0;
        unsigned int j;
	short *silence;
	snd_pcm_sframes_t avail = -1;
	snd_pcm_uframes_t min_period_size;
	snd_pcm_uframes_t boundary;
	int dir;

        snd_pcm_t *handle;
	snd_output_t *out = NULL;

	snd_pcm_hw_params_t *params;
	snd_pcm_sw_params_t *swparams;

	snd_pcm_hw_params_alloca(&params);
	snd_pcm_sw_params_alloca(&swparams);

	snd_output_stdio_attach(&out, stderr, 0);
	silence = calloc(period_size * periods, sizeof(short) * channels);

	if ((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < 0) {
		fprintf(stderr, "Playback open error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	failed =           (err = snd_pcm_hw_params_any(handle, params)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate_resample(handle, params, 1)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_channels(handle, params, channels)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate(handle, params, rate, 0)) < 0;

	if (failed) {
		fprintf(stderr, "Playback hwparams (access & format) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_period_size_min(params, &min_period_size, &dir);
	if (err < 0) {
		fprintf(stderr, "Cannot get minimum period size: %s\n", snd_strerror(err));
	}

	fprintf(stderr, "min_period_size: %d frames, dir: %d\n", (int)min_period_size, dir);

	failed =           (err = snd_pcm_hw_params_set_period_size(handle, params, period_size, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_periods(handle, params, periods, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params(handle, params)) < 0;
	if (failed) {
		fprintf(stderr, "Playback hwparams (period size & periods) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_fifo_size(params);
	if (err < 0) {
		fprintf(stderr, "Playback hwparams: can't get FIFO size, error: %s\n", snd_strerror(err));
	} else {
		fprintf(stderr, "Playback hwparams: FIFO size is %d\n", err);
	}

	failed =           (err = snd_pcm_sw_params_current(handle, swparams)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_start_threshold(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_avail_min(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params(handle, swparams)) < 0;
	if (failed) {
		fprintf(stderr, "Playback swparams error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	snd_pcm_dump(handle, out);
	fprintf(stderr, "Playing silence\n");
	fflush(stderr);
	memset(silence, 0, period_size * periods * sizeof(short) * channels);
	err = snd_pcm_writei(handle, silence, period_size * periods);
	if (err < 0) {
		fprintf(stderr, "Playback error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	j = 0;
	while (1) {
		snd_pcm_sframes_t avail1 = snd_pcm_avail(handle);
		if (avail1 < 0)
			break;
		if (avail != avail1) {
			fprintf(stderr, "Available: %d, loop iteration: %d\n", (int)avail1, j);
		}
		avail = avail1;
		j++;
	}
	snd_pcm_drop(handle);
	snd_pcm_close(handle);

	free(silence);
	return 0;
}

[-- Attachment #3: report.txt --]
[-- Type: text/plain, Size: 22544 bytes --]

min_period_size: 16 frames, dir: 0
Playback hwparams: FIFO size is 0
Hardware PCM card 0 'Xonar DX' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1024
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0
Playing silence
Available: 16, loop iteration: 0
Available: 32, loop iteration: 1
Available: 40, loop iteration: 2
Available: 49, loop iteration: 3
Available: 56, loop iteration: 4
Available: 64, loop iteration: 5
Available: 72, loop iteration: 6
Available: 88, loop iteration: 7
Available: 96, loop iteration: 8
Available: 112, loop iteration: 9
Available: 120, loop iteration: 10
Available: 128, loop iteration: 11
Available: 144, loop iteration: 12
Available: 152, loop iteration: 13
Available: 164, loop iteration: 14
Available: 168, loop iteration: 15
Available: 176, loop iteration: 16
Available: 192, loop iteration: 17
Available: 200, loop iteration: 18
Available: 213, loop iteration: 19
Available: 216, loop iteration: 20
Available: 224, loop iteration: 21
Available: 240, loop iteration: 22
Available: 248, loop iteration: 23
Available: 256, loop iteration: 24
Available: 264, loop iteration: 66
Available: 272, loop iteration: 142
Available: 280, loop iteration: 219
Available: 286, loop iteration: 295
Available: 288, loop iteration: 296
Available: 296, loop iteration: 371
Available: 304, loop iteration: 447
Available: 312, loop iteration: 524
Available: 315, loop iteration: 600
Available: 320, loop iteration: 601
Available: 328, loop iteration: 676
Available: 336, loop iteration: 753
Available: 337, loop iteration: 829
Available: 344, loop iteration: 830
Available: 352, loop iteration: 905
Available: 360, loop iteration: 982
Available: 368, loop iteration: 1054
Available: 376, loop iteration: 1130
Available: 384, loop iteration: 1207
Available: 392, loop iteration: 1283
Available: 400, loop iteration: 1360
Available: 403, loop iteration: 1436
Available: 408, loop iteration: 1437
Available: 414, loop iteration: 1512
Available: 416, loop iteration: 1513
Available: 424, loop iteration: 1588
Available: 432, loop iteration: 1665
Available: 440, loop iteration: 1741
Available: 448, loop iteration: 1818
Available: 456, loop iteration: 1894
Available: 464, loop iteration: 1971
Available: 472, loop iteration: 2047
Available: 480, loop iteration: 2124
Available: 488, loop iteration: 2200
Available: 496, loop iteration: 2277
Available: 498, loop iteration: 2353
Available: 504, loop iteration: 2354
Available: 510, loop iteration: 2429
Available: 512, loop iteration: 2430
Available: 520, loop iteration: 2505
Available: 528, loop iteration: 2582
Available: 536, loop iteration: 2658
Available: 544, loop iteration: 2735
Available: 552, loop iteration: 2811
Available: 560, loop iteration: 2881
Available: 561, loop iteration: 2960
Available: 568, loop iteration: 2961
Available: 570, loop iteration: 3046
Available: 576, loop iteration: 3047
Available: 584, loop iteration: 3133
Available: 592, loop iteration: 3220
Available: 600, loop iteration: 3303
Available: 608, loop iteration: 3389
Available: 616, loop iteration: 3476
Available: 624, loop iteration: 3563
Available: 625, loop iteration: 3650
Available: 630, loop iteration: 3651
Available: 632, loop iteration: 3652
Available: 640, loop iteration: 3733
Available: 648, loop iteration: 3818
Available: 656, loop iteration: 3901
Available: 664, loop iteration: 3940
Available: 672, loop iteration: 4009
Available: 680, loop iteration: 4091
Available: 688, loop iteration: 4170
Available: 696, loop iteration: 4211
Available: 700, loop iteration: 4278
Available: 704, loop iteration: 4279
Available: 712, loop iteration: 4363
Available: 720, loop iteration: 4447
Available: 725, loop iteration: 4527
Available: 728, loop iteration: 4528
Available: 736, loop iteration: 4613
Available: 744, loop iteration: 4696
Available: 752, loop iteration: 4774
Available: 760, loop iteration: 4856
Available: 768, loop iteration: 4940
Available: 776, loop iteration: 5024
Available: 779, loop iteration: 5108
Available: 784, loop iteration: 5109
Available: 792, loop iteration: 5194
Available: 800, loop iteration: 5274
Available: 808, loop iteration: 5359
Available: 816, loop iteration: 5445
Available: 820, loop iteration: 5532
Available: 824, loop iteration: 5533
Available: 832, loop iteration: 5619
Available: 835, loop iteration: 5706
Available: 840, loop iteration: 5707
Available: 848, loop iteration: 5793
Available: 856, loop iteration: 5881
Available: 864, loop iteration: 5968
Available: 872, loop iteration: 6056
Available: 880, loop iteration: 6143
Available: 888, loop iteration: 6228
Available: 891, loop iteration: 6270
Available: 893, loop iteration: 6271
Available: 896, loop iteration: 6272
Available: 904, loop iteration: 6357
Available: 912, loop iteration: 6444
Available: 920, loop iteration: 6532
Available: 928, loop iteration: 6619
Available: 936, loop iteration: 6706
Available: 944, loop iteration: 6786
Available: 952, loop iteration: 6873
Available: 960, loop iteration: 6960
Available: 961, loop iteration: 7046
Available: 968, loop iteration: 7047
Available: 976, loop iteration: 7133
Available: 984, loop iteration: 7220
Available: 992, loop iteration: 7307
Available: 1000, loop iteration: 7394
Available: 1008, loop iteration: 7481
Available: 1016, loop iteration: 7568
Available: 1024, loop iteration: 7655
Available: 1032, loop iteration: 7738
Available: 1040, loop iteration: 7825
Available: 1048, loop iteration: 7912
Available: 1056, loop iteration: 7999
Available: 1064, loop iteration: 8086
Available: 1072, loop iteration: 8173
Available: 1080, loop iteration: 8260
Available: 1088, loop iteration: 8347
Available: 1096, loop iteration: 8434
Available: 1104, loop iteration: 8521
Available: 1112, loop iteration: 8608
Available: 1120, loop iteration: 8695
Available: 1128, loop iteration: 8782
Available: 1136, loop iteration: 8863
Available: 1144, loop iteration: 8949
Available: 1152, loop iteration: 9034
Available: 1160, loop iteration: 9119
Available: 1168, loop iteration: 9206
Available: 1170, loop iteration: 9293
Available: 1174, loop iteration: 9294
Available: 1176, loop iteration: 9295
Available: 1184, loop iteration: 9380
Available: 1192, loop iteration: 9466
Available: 1200, loop iteration: 9554
Available: 1208, loop iteration: 9641
Available: 1216, loop iteration: 9729
Available: 1220, loop iteration: 9816
Available: 1224, loop iteration: 9817
Available: 1232, loop iteration: 9903
Available: 1240, loop iteration: 9991
Available: 1248, loop iteration: 10078
Available: 1256, loop iteration: 10166
Available: 1264, loop iteration: 10253
Available: 1272, loop iteration: 10340
Available: 1280, loop iteration: 10427
Available: 1288, loop iteration: 10515
Available: 1296, loop iteration: 10602
Available: 1299, loop iteration: 10689
Available: 1304, loop iteration: 10690
Available: 1312, loop iteration: 10776
Available: 1313, loop iteration: 10863
Available: 1320, loop iteration: 10864
Available: 1328, loop iteration: 10948
Available: 1336, loop iteration: 11033
Available: 1344, loop iteration: 11120
Available: 1352, loop iteration: 11207
Available: 1360, loop iteration: 11295
Available: 1368, loop iteration: 11382
Available: 1376, loop iteration: 11468
Available: 1377, loop iteration: 11553
Available: 1384, loop iteration: 11554
Available: 1392, loop iteration: 11637
Available: 1400, loop iteration: 11722
Available: 1405, loop iteration: 11806
Available: 1408, loop iteration: 11807
Available: 1409, loop iteration: 11891
Available: 1416, loop iteration: 11892
Available: 1424, loop iteration: 11976
Available: 1432, loop iteration: 12056
Available: 1440, loop iteration: 12142
Available: 1448, loop iteration: 12229
Available: 1456, loop iteration: 12317
Available: 1464, loop iteration: 12404
Available: 1472, loop iteration: 12491
Available: 1480, loop iteration: 12578
Available: 1488, loop iteration: 12665
Available: 1496, loop iteration: 12753
Available: 1504, loop iteration: 12840
Available: 1512, loop iteration: 12927
Available: 1520, loop iteration: 12947
Available: 1528, loop iteration: 13026
Available: 1536, loop iteration: 13107
Available: 1544, loop iteration: 13180
Available: 1552, loop iteration: 13257
Available: 1553, loop iteration: 13331
Available: 1560, loop iteration: 13332
Available: 1568, loop iteration: 13400
Available: 1576, loop iteration: 13478
Available: 1584, loop iteration: 13560
Available: 1592, loop iteration: 13642
Available: 1600, loop iteration: 13724
Available: 1608, loop iteration: 13806
Available: 1616, loop iteration: 13888
Available: 1624, loop iteration: 13965
Available: 1626, loop iteration: 14043
Available: 1632, loop iteration: 14044
Available: 1640, loop iteration: 14117
Available: 1648, loop iteration: 14196
Available: 1656, loop iteration: 14275
Available: 1664, loop iteration: 14355
Available: 1672, loop iteration: 14435
Available: 1680, loop iteration: 14515
Available: 1688, loop iteration: 14595
Available: 1696, loop iteration: 14640
Available: 1704, loop iteration: 14717
Available: 1712, loop iteration: 14791
Available: 1720, loop iteration: 14871
Available: 1728, loop iteration: 14951
Available: 1736, loop iteration: 15031
Available: 1744, loop iteration: 15111
Available: 1752, loop iteration: 15192
Available: 1756, loop iteration: 15271
Available: 1760, loop iteration: 15272
Available: 1768, loop iteration: 15342
Available: 1776, loop iteration: 15423
Available: 1784, loop iteration: 15509
Available: 1792, loop iteration: 15596
Available: 1800, loop iteration: 15683
Available: 1808, loop iteration: 15770
Available: 1816, loop iteration: 15854
Available: 1824, loop iteration: 15934
Available: 1832, loop iteration: 16021
Available: 1840, loop iteration: 16108
Available: 1848, loop iteration: 16195
Available: 1856, loop iteration: 16282
Available: 1864, loop iteration: 16369
Available: 1872, loop iteration: 16456
Available: 1880, loop iteration: 16543
Available: 1888, loop iteration: 16630
Available: 1896, loop iteration: 16718
Available: 1904, loop iteration: 16803
Available: 1906, loop iteration: 16889
Available: 1912, loop iteration: 16890
Available: 1920, loop iteration: 16976
Available: 1928, loop iteration: 17063
Available: 1936, loop iteration: 17150
Available: 1944, loop iteration: 17237
Available: 1952, loop iteration: 17324
Available: 1960, loop iteration: 17411
Available: 1968, loop iteration: 17498
Available: 1976, loop iteration: 17585
Available: 1981, loop iteration: 17671
Available: 1984, loop iteration: 17672
Available: 1992, loop iteration: 17758
Available: 2000, loop iteration: 17845
Available: 2008, loop iteration: 17931
Available: 2016, loop iteration: 18018
Available: 2024, loop iteration: 18105
Available: 2032, loop iteration: 18192
Available: 2040, loop iteration: 18279
Available: 2048, loop iteration: 18366
Available: 2056, loop iteration: 18449
Available: 2064, loop iteration: 18536
Available: 2072, loop iteration: 18623
Available: 2080, loop iteration: 18710
Available: 2088, loop iteration: 18797
Available: 2096, loop iteration: 18882
Available: 2104, loop iteration: 18969
Available: 2112, loop iteration: 19056
Available: 2120, loop iteration: 19143
Available: 2128, loop iteration: 19230
Available: 2136, loop iteration: 19317
Available: 2144, loop iteration: 19404
Available: 2146, loop iteration: 19490
Available: 2152, loop iteration: 19491
Available: 2160, loop iteration: 19577
Available: 2168, loop iteration: 19664
Available: 2176, loop iteration: 19751
Available: 2184, loop iteration: 19838
Available: 2192, loop iteration: 19925
Available: 2200, loop iteration: 20012
Available: 2208, loop iteration: 20099
Available: 2216, loop iteration: 20186
Available: 2224, loop iteration: 20273
Available: 2229, loop iteration: 20359
Available: 2232, loop iteration: 20360
Available: 2240, loop iteration: 20446
Available: 2248, loop iteration: 20533
Available: 2256, loop iteration: 20618
Available: 2264, loop iteration: 20705
Available: 2272, loop iteration: 20792
Available: 2280, loop iteration: 20879
Available: 2288, loop iteration: 20963
Available: 2296, loop iteration: 21049
Available: 2297, loop iteration: 21135
Available: 2304, loop iteration: 21136
Available: 2312, loop iteration: 21222
Available: 2320, loop iteration: 21309
Available: 2326, loop iteration: 21395
Available: 2328, loop iteration: 21396
Available: 2336, loop iteration: 21482
Available: 2337, loop iteration: 21568
Available: 2344, loop iteration: 21569
Available: 2352, loop iteration: 21655
Available: 2360, loop iteration: 21742
Available: 2368, loop iteration: 21829
Available: 2376, loop iteration: 21916
Available: 2384, loop iteration: 22003
Available: 2392, loop iteration: 22090
Available: 2400, loop iteration: 22177
Available: 2408, loop iteration: 22264
Available: 2416, loop iteration: 22351
Available: 2424, loop iteration: 22438
Available: 2432, loop iteration: 22525
Available: 2440, loop iteration: 22612
Available: 2448, loop iteration: 22698
Available: 2456, loop iteration: 22785
Available: 2464, loop iteration: 22872
Available: 2472, loop iteration: 22959
Available: 2480, loop iteration: 23045
Available: 2488, loop iteration: 23132
Available: 2496, loop iteration: 23181
Available: 2497, loop iteration: 23259
Available: 2504, loop iteration: 23260
Available: 2512, loop iteration: 23345
Available: 2520, loop iteration: 23432
Available: 2528, loop iteration: 23519
Available: 2536, loop iteration: 23606
Available: 2544, loop iteration: 23693
Available: 2552, loop iteration: 23780
Available: 2560, loop iteration: 23867
Available: 2568, loop iteration: 23954
Available: 2576, loop iteration: 24041
Available: 2584, loop iteration: 24128
Available: 2590, loop iteration: 24214
Available: 2592, loop iteration: 24215
Available: 2600, loop iteration: 24301
Available: 2608, loop iteration: 24388
Available: 2616, loop iteration: 24475
Available: 2624, loop iteration: 24562
Available: 2632, loop iteration: 24649
Available: 2640, loop iteration: 24736
Available: 2644, loop iteration: 24822
Available: 2648, loop iteration: 24823
Available: 2656, loop iteration: 24909
Available: 2664, loop iteration: 24996
Available: 2672, loop iteration: 25081
Available: 2680, loop iteration: 25168
Available: 2688, loop iteration: 25255
Available: 2696, loop iteration: 25342
Available: 2704, loop iteration: 25429
Available: 2712, loop iteration: 25516
Available: 2715, loop iteration: 25602
Available: 2720, loop iteration: 25603
Available: 2728, loop iteration: 25689
Available: 2736, loop iteration: 25776
Available: 2744, loop iteration: 25863
Available: 2752, loop iteration: 25950
Available: 2760, loop iteration: 26037
Available: 2768, loop iteration: 26124
Available: 2771, loop iteration: 26210
Available: 2776, loop iteration: 26211
Available: 2784, loop iteration: 26297
Available: 2792, loop iteration: 26383
Available: 2800, loop iteration: 26464
Available: 2805, loop iteration: 26550
Available: 2808, loop iteration: 26551
Available: 2816, loop iteration: 26637
Available: 2824, loop iteration: 26724
Available: 2832, loop iteration: 26811
Available: 2840, loop iteration: 26898
Available: 2846, loop iteration: 26984
Available: 2848, loop iteration: 26985
Available: 2856, loop iteration: 27071
Available: 2864, loop iteration: 27155
Available: 2868, loop iteration: 27241
Available: 2872, loop iteration: 27242
Available: 2880, loop iteration: 27328
Available: 2888, loop iteration: 27415
Available: 2896, loop iteration: 27502
Available: 2898, loop iteration: 27588
Available: 2904, loop iteration: 27589
Available: 2912, loop iteration: 27675
Available: 2920, loop iteration: 27762
Available: 2928, loop iteration: 27846
Available: 2933, loop iteration: 27932
Available: 2936, loop iteration: 27933
Available: 2944, loop iteration: 28019
Available: 2952, loop iteration: 28106
Available: 2960, loop iteration: 28193
Available: 2962, loop iteration: 28279
Available: 2968, loop iteration: 28280
Available: 2976, loop iteration: 28366
Available: 2984, loop iteration: 28453
Available: 2992, loop iteration: 28539
Available: 3000, loop iteration: 28626
Available: 3008, loop iteration: 28713
Available: 3016, loop iteration: 28800
Available: 3024, loop iteration: 28887
Available: 3032, loop iteration: 28974
Available: 3040, loop iteration: 29061
Available: 3048, loop iteration: 29148
Available: 3056, loop iteration: 29233
Available: 3064, loop iteration: 29320
Available: 3072, loop iteration: 29407
Available: 3080, loop iteration: 29488
Available: 3088, loop iteration: 29575
Available: 3096, loop iteration: 29662
Available: 3104, loop iteration: 29749
Available: 3112, loop iteration: 29836
Available: 3120, loop iteration: 29923
Available: 3128, loop iteration: 30010
Available: 3136, loop iteration: 30097
Available: 3144, loop iteration: 30184
Available: 3152, loop iteration: 30271
Available: 3160, loop iteration: 30358
Available: 3165, loop iteration: 30444
Available: 3168, loop iteration: 30445
Available: 3176, loop iteration: 30531
Available: 3184, loop iteration: 30618
Available: 3192, loop iteration: 30705
Available: 3200, loop iteration: 30792
Available: 3208, loop iteration: 30879
Available: 3212, loop iteration: 30965
Available: 3216, loop iteration: 30966
Available: 3224, loop iteration: 31052
Available: 3232, loop iteration: 31139
Available: 3233, loop iteration: 31225
Available: 3240, loop iteration: 31226
Available: 3248, loop iteration: 31310
Available: 3256, loop iteration: 31390
Available: 3258, loop iteration: 31471
Available: 3264, loop iteration: 31472
Available: 3265, loop iteration: 31547
Available: 3272, loop iteration: 31548
Available: 3280, loop iteration: 31623
Available: 3288, loop iteration: 31701
Available: 3289, loop iteration: 31762
Available: 3296, loop iteration: 31763
Available: 3304, loop iteration: 31838
Available: 3312, loop iteration: 31919
Available: 3320, loop iteration: 32001
Available: 3328, loop iteration: 32083
Available: 3336, loop iteration: 32164
Available: 3344, loop iteration: 32243
Available: 3349, loop iteration: 32322
Available: 3352, loop iteration: 32323
Available: 3360, loop iteration: 32396
Available: 3368, loop iteration: 32476
Available: 3376, loop iteration: 32555
Available: 3384, loop iteration: 32631
Available: 3392, loop iteration: 32706
Available: 3400, loop iteration: 32780
Available: 3408, loop iteration: 32853
Available: 3416, loop iteration: 32927
Available: 3424, loop iteration: 33001
Available: 3432, loop iteration: 33074
Available: 3440, loop iteration: 33143
Available: 3442, loop iteration: 33215
Available: 3448, loop iteration: 33216
Available: 3452, loop iteration: 33282
Available: 3456, loop iteration: 33283
Available: 3464, loop iteration: 33351
Available: 3472, loop iteration: 33426
Available: 3480, loop iteration: 33502
Available: 3488, loop iteration: 33579
Available: 3496, loop iteration: 33655
Available: 3504, loop iteration: 33736
Available: 3512, loop iteration: 33817
Available: 3520, loop iteration: 33899
Available: 3528, loop iteration: 33981
Available: 3536, loop iteration: 34063
Available: 3544, loop iteration: 34144
Available: 3552, loop iteration: 34222
Available: 3553, loop iteration: 34300
Available: 3560, loop iteration: 34301
Available: 3568, loop iteration: 34374
Available: 3576, loop iteration: 34453
Available: 3578, loop iteration: 34533
Available: 3584, loop iteration: 34534
Available: 3592, loop iteration: 34608
Available: 3600, loop iteration: 34688
Available: 3608, loop iteration: 34768
Available: 3616, loop iteration: 34848
Available: 3624, loop iteration: 34928
Available: 3632, loop iteration: 35004
Available: 3640, loop iteration: 35083
Available: 3648, loop iteration: 35163
Available: 3656, loop iteration: 35244
Available: 3664, loop iteration: 35324
Available: 3666, loop iteration: 35403
Available: 3672, loop iteration: 35404
Available: 3680, loop iteration: 35478
Available: 3688, loop iteration: 35557
Available: 3696, loop iteration: 35635
Available: 3697, loop iteration: 35716
Available: 3704, loop iteration: 35717
Available: 3706, loop iteration: 35801
Available: 3712, loop iteration: 35802
Available: 3720, loop iteration: 35887
Available: 3728, loop iteration: 35974
Available: 3736, loop iteration: 36061
Available: 3744, loop iteration: 36148
Available: 3752, loop iteration: 36235
Available: 3760, loop iteration: 36322
Available: 3761, loop iteration: 36407
Available: 3768, loop iteration: 36408
Available: 3776, loop iteration: 36482
Available: 3784, loop iteration: 36568
Available: 3792, loop iteration: 36655
Available: 3800, loop iteration: 36742
Available: 3808, loop iteration: 36829
Available: 3809, loop iteration: 36915
Available: 3816, loop iteration: 36916
Available: 3824, loop iteration: 37000
Available: 3832, loop iteration: 37087
Available: 3840, loop iteration: 37174
Available: 3848, loop iteration: 37261
Available: 3856, loop iteration: 37348
Available: 3864, loop iteration: 37435
Available: 3872, loop iteration: 37522
Available: 3880, loop iteration: 37609
Available: 3888, loop iteration: 37696
Available: 3896, loop iteration: 37783
Available: 3899, loop iteration: 37869
Available: 3904, loop iteration: 37870
Available: 3912, loop iteration: 37956
Available: 3920, loop iteration: 38043
Available: 3928, loop iteration: 38130
Available: 3936, loop iteration: 38217
Available: 3937, loop iteration: 38303
Available: 3944, loop iteration: 38304
Available: 3952, loop iteration: 38390
Available: 3960, loop iteration: 38477
Available: 3968, loop iteration: 38564
Available: 3976, loop iteration: 38651
Available: 3984, loop iteration: 38737
Available: 3992, loop iteration: 38824
Available: 4000, loop iteration: 38911
Available: 4008, loop iteration: 38998
Available: 4016, loop iteration: 39081
Available: 4024, loop iteration: 39168
Available: 4032, loop iteration: 39255
Available: 4040, loop iteration: 39342
Available: 4048, loop iteration: 39429
Available: 4056, loop iteration: 39516
Available: 4058, loop iteration: 39602
Available: 4064, loop iteration: 39603
Available: 4072, loop iteration: 39689
Available: 4080, loop iteration: 39776
Available: 4088, loop iteration: 39863

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: Master Plan on rewinding

[Raymond Yau]

> > Does snd-oxygen provide this position with granularity which is less
than
> > the minimum period size ?
>
> Yes.  Its DMA controller uses a burst size of 32 bytes.  The pointer
registers
> are documented as reporting the position with 4-byte accuracy, but there
were
> problems when the period/buffer sizes were not aligned to 32 bytes.  I've
set
> the minimum period size to 64 bytes, just to be safe.
>
>

The brust size is usually added to the constriants but the application
cannot deduce this value

err = snd_pcm_hw_constraint_step(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 32);

For those audio controllers have FIFO buffer, the application must keep the
FIFO buffer full at any time for glitch free.

Someone may argue that keeping at least one frame above FIFO threshold is
just enough

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081509.html

I don't understand why the minimum buffer size can be less than FIFO size

Re: Master Plan on rewinding

[Lars-Peter Clausen]

On 09/21/2014 04:02 AM, Raymond Yau wrote:
[...]
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc/soc-generic-dmaengine-pcm.c?id=478028e088d6a94666d8a776be2cd2291faf3bbd
>
> a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse.
> b) Fallback to the (race condition prone) period counting if the driver
> does not support any residue reporting.
>
> Seem soc already have this granularity
>
> How can the granularity worse more than one period ?

The granularity is the granularity that the DMA driver is able to report. In 
some cases the DMA driver is only able to tell whether a transfer has 
finished or not, but is not able tell any intermediate position. In case of 
a cyclic transfer the transfer never stops, so the DMA driver will only ever 
tell us that it hasn't finished the transfer yet. But the DMA driver will 
still generate a interrupt after every finished period. So we use this as a 
fallback mechanism and simply increase the pointer position after each 
interrupt by one period size. So userspace will never see a granularity that 
is worse than one descriptor. This is just something kernel internal.

On a side node, this period counting scheme is prone to race conditions and 
we strongly discourage new drivers from using it. Its mainly for supporting 
old DMA drivers which do not implement progress reporting (yet).

>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h
>
> enum dma_residue_granularity {
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0,
> DMA_RESIDUE_GRANULARITY_SEGMENT = 1,
> DMA_RESIDUE_GRANULARITY_BURST = 2,
> };
>
> There are three type of granularity

Only SEGMENT and BURST granularity are relevant for audio userspace.

For ALSA we'd probably see different kind of categories of granularity 
though. E.g. one field which is the unit of the granularity

PERIOD: The granularity is a multiple of the period size
FRAME: The granularity is a multiple of the frame size
BYTE: The granularity is a fixed number of bytes
MS: The granularity is a fixed amount of time

and then a second field that has a integer number of the granularity in that 
unit.


And then there is of course the issue that for some chips you can trade 
granularity for e.g. power efficiency or similar (e.g. by changing the 
transfer burst size). And this needs to be modeled somehow as well.

>
> Does this mean the those sound card can report
> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer callback ?
>
> A few PCI sound cards use SG buffer including hda
>
> It seem that pulseaudio expect the driver support
> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling

Yes. This is why we set the BATCH flag if the granularity is not 
DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable timer 
scheduling.

- Lars

Re: Master Plan on rewinding

[Alexander E. Patrakov]

22.09.2014 19:20, Lars-Peter Clausen wrote:
>>
>> Does this mean the those sound card can report
>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer
>> callback ?
>>
>> A few PCI sound cards use SG buffer including hda
>>
>> It seem that pulseaudio expect the driver support
>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling
>
> Yes. This is why we set the BATCH flag if the granularity is not
> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable
> timer scheduling.

For the record, disabling timer-based scheduling is IMHO a matter of 
further discussion. As long as there is enough safeguard, I think that 
timer-based scheduling can still be used, and is useful. A living proof 
is the whole story with the snd-usb-audio driver where (justified) 
addition of the BATCH flag was perceived as a performance regression and 
not as a fix to some real and obvious problem.

I do agree that such devices need to be marked up with the BATCH flag, 
so that PulseAudio chooses reasonable hardware parameters.

-- 
Alexander E. Patrakov

Re: Master Plan on rewinding

[Lars-Peter Clausen]

On 09/22/2014 03:36 PM, Alexander E. Patrakov wrote:
> 22.09.2014 19:20, Lars-Peter Clausen wrote:
>>>
>>> Does this mean the those sound card can report
>>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer
>>> callback ?
>>>
>>> A few PCI sound cards use SG buffer including hda
>>>
>>> It seem that pulseaudio expect the driver support
>>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling
>>
>> Yes. This is why we set the BATCH flag if the granularity is not
>> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable
>> timer scheduling.
>
> For the record, disabling timer-based scheduling is IMHO a matter of further
> discussion. As long as there is enough safeguard, I think that timer-based
> scheduling can still be used, and is useful. A living proof is the whole
> story with the snd-usb-audio driver where (justified) addition of the BATCH
> flag was perceived as a performance regression and not as a fix to some real
> and obvious problem.
>
> I do agree that such devices need to be marked up with the BATCH flag, so
> that PulseAudio chooses reasonable hardware parameters.
>

When I tried things it looks like it was more than just the safeguard 
threshold. It looked as if the algorithm that adjusts the wake-up time gets 
confused if the granularity is not good enough and just wakes up at the 
wrong point which leads to glitches. This can probably be fixed though by 
modifying the algorithm to take the granularity into account.

- Lars

Re: Master Plan on rewinding

[Raymond Yau]

>>>
>>>
>>> Does this mean the those sound card can report
>>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer
>>> callback ?
>>>
>>> A few PCI sound cards use SG buffer including hda
>>>
>>> It seem that pulseaudio expect the driver support
>>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling
>>
>>
>> Yes. This is why we set the BATCH flag if the granularity is not
>> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable
>> timer scheduling.
>

The resolution of pulseaudio volume is higher than the number of steps of
the hardware volume control, this mean any volume change by user force
pulseaudio to rewind  because of the change in software volume

As user won't expect the volume change is delayed by one second

Those drivers should not use 2 periods as graunulaity is one period which
is  170ms ~1 second if you are running video conference (e.g. Google
hangout) when video is 15~30 frames per second

The safeguard can only be decreased by reduce the period size

Is it feasible for pulseaudio to use more periods with  suitable period
size/time for the requested latency when there is one and only one client
when the sound card cannot provide precise DMA position instead of maximum
period size/time ?

>
> For the record, disabling timer-based scheduling is IMHO a matter of
further discussion. As long as there is enough safeguard, I think that
timer-based scheduling can still be used, and is useful. A living proof is
the whole story with the snd-usb-audio driver where (justified) addition of
the BATCH flag was perceived as a performance regression and not as a fix
to some real and obvious problem.

The point is some drivers use .periods_min = 1

Pulseaudio select minimum number of period

interrupt driven mode should not use one period per buffer since
granularity is one period

one period per buffer work only when sound card can report granularity
which is less than one period

aplay won't use one period per buffer , default is four but fallback to two
when driver use .periods_max = 2

http://0pointer.net/blog/projects/pulse-glitch-free.html

NFRAGS must >= 2

Re: Master Plan on rewinding

[Alexander E. Patrakov]

23.09.2014 14:29, Raymond Yau wrote:
>
>  >>>
>  >>>
>  >>> Does this mean the those sound card can report
>  >>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer
>  >>> callback ?
>  >>>
>  >>> A few PCI sound cards use SG buffer including hda
>  >>>
>  >>> It seem that pulseaudio expect the driver support
>  >>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling
>  >>
>  >>
>  >> Yes. This is why we set the BATCH flag if the granularity is not
>  >> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable
>  >> timer scheduling.
>  >
>
> The resolution of pulseaudio volume is higher than the number of steps
> of the hardware volume control, this mean any volume change by user
> force pulseaudio to rewind  because of the change in software volume
>
> As user won't expect the volume change is delayed by one second

Absolutely correct, and a similar thing was already discussed. The 
interesting part of the discussion starts here:

http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-April/020462.html

Please disregard my "factor of 1000" statement - it is no longer true.

> Those drivers should not use 2 periods as graunulaity is one period
> which is  170ms ~1 second if you are running video conference (e.g.
> Google hangout) when video is 15~30 frames per second
>
> The safeguard can only be decreased by reduce the period size

Also correct for the BATCH cards. However, please note that for the 
BATCH cards PulseAudio looks at the default-fragment-size-msec setting 
from daemon.conf by default.

> Is it feasible for pulseaudio to use more periods with  suitable period
> size/time for the requested latency when there is one and only one
> client when the sound card cannot provide precise DMA position instead
> of maximum period size/time ?

Probably not, because the rewinds are exposed in the public PulseAudio 
APIs (in particular, via the last two parameters of pa_stream_write()). 
So it definitely should not use the maximum period time, but should also 
not derive one from the client-requested latency. A hard-coded default 
or a default from the config (i.e. the current situation) is therefore 
as good as one can get on BATCH cards regarding the period size.

>
>  >
>  > For the record, disabling timer-based scheduling is IMHO a matter of
> further discussion. As long as there is enough safeguard, I think that
> timer-based scheduling can still be used, and is useful. A living proof
> is the whole story with the snd-usb-audio driver where (justified)
> addition of the BATCH flag was perceived as a performance regression and
> not as a fix to some real and obvious problem.
>
> The point is some drivers use .periods_min = 1
>
> Pulseaudio select minimum number of period

It does not do that on BATCH cards. Or if it does, it is a bug.

As for the rest of your arguments, you are just stating obvious and 
correct things, so I see no point in quoting them.

Indeed, most of the work on PulseAudio side would mean choosing the 
correct period size, number of periods, wakeup threshold and rewind 
granularity for each possible situation. I should just do it when the 
needed API appears on the ALSA side :)

-- 
Alexander E. Patrakov