[alsa-devel] [PATCH v2] ALSA: core: let low-level driver or userspace disable rewinds

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Tue Jun 13 15:13:35 CEST 2017


On 6/13/17 7:09 AM, Takashi Sakamoto wrote:
> Pierre-Louis,
>
> On Jun 12 2017 21:09, Pierre-Louis Bossart wrote:
>>> If describing the detail design of your hardware, you might get more
>>> helps.
>>>
>>>  * I intentionally ignore discussion about burstness of data
>>>    transmission and accuracy of hwptr.
>>
>> You are probably reading too much into this.
>> The intent is to optimize DMA operations where the hardware now knows
>> both hw_ptr and appl_ptr. there is no use of the .ack() for copies into
>> intermediate buffers
>
> If this patch included enough explanation about the disadvantage of
> rewind operation on your driver and hardware in a point of optimization
> for DMA data transmission and power consumption, I would not have driven
> my imagination so hard for the reviewing.

Maybe you missed what we wrote in the commit message:
"this can be used by low-level driver to optimize DMA operations
and reduce power consumption."
There will be follow-up patches that make use of this capability on 
Intel platforms but for now this is hardware-agnostic.

>
>> and the code for rewind on capture is largely for
>> consistency - we've never seen anyone using rewind on capture on
>> DSP-based platforms.
>
> I'm not a prophet, and you too. It's not better to change interfaces
> with any forecast. Furthermore, once changing interfaces, it affects to
> all of applications. Please have enough care of it.

I don't get what you are saying. There is no interface or behavior 
change, disabling rewinds is strictly opt-in and controlled from the 
application. I was just stating that we have not seen anyone use rewinds 
on capture and at this point we have no need to disable non-existent 
usages...

>
> # I can imagine a disadvantage of rewind operation for PCM capture
> # substream. When rewinding, available space on PCM buffer for data
> # transmission from hardware is reduced. Then, even if hardware already
> # done sampling, it can't transfer the PCM frames. There's a delay and
> # hardware needs extra buffering.
>
>
> Regards
>
> Takashi Sakamoto
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



More information about the Alsa-devel mailing list