Change the use of host_period_bytes. So far this field was used
as an bool value indicating whether FW should send stream position
update. With this patch we use host_period_bytes to provide firmware
information about the frequency of host interrupts aimed to read
its input buffer. This is accoring to ALSA definition of 'FramePeriod'.
according to the
Knowing this firmware can safely copy large/irregular chunks of data
why irregular? ALSA periods are pretty regular and predictable.
I did not say ALSA periods are irregular I said that sometimes (like in
case of draining) firmware needs to copy irregular amount of that.
What I mean by "irregular" is not equal to ALSA period or multiple of
periods.
Marcin, in the v2 review this is what we discussed. The formatting may
be off so please refer to the emails directly should this be difficult
to read:
"
>>>
>>> Before I provide more feedback, can you clarify if the
'host_period_bytes' is the same value as the ALSA period size (in
bytes)? And what would be the value when the no_irq mode is used?
>>
>> Yes, this is the same value. It is obtained by
*params_period_bytes**()* in kernel.
>
> ok good. I was afraid this would be a different concept.
>
> So what you are saying is that the draining happens by bursts whose
size is tied to the period defined by the host, yes?
Yes. We try to fill host buffer as much as we can to gain fast draining
but in the same time we give host time to read it.
"
I cannot reconcile the two threads, is the draining tied to the ALSA
period size or not?
Care to clarify?
(like data comming from i.e draining task) without the risk of buffer
coming
Please proof-read your commit messages (and use an editor which
spell-checks for you), typos and misleading information don't exactly
boost trust in the suggested patch, regardless of its merits.
Sorry for typos. Should I correct them and resend again or correct here
as we discuss?
better send a v5 when we've clarified what the 'irregular' wording
refers to.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
