lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 May 2020 12:18:45 +0000
To:     Mark Brown <>,
        "Agrawal, Akshu" <>
CC:     Liam Girdwood <>,
        Jaroslav Kysela <>,
        Takashi Iwai <>,
        "Mukunda, Vijendar" <>,
        Colin Ian King <>,
        Kuninori Morimoto <>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        open list <>
Subject: RE: [PATCH] ASoC: amd :High hw_level while simultaneous capture

[AMD Official Use Only - Internal Distribution Only]

-----Original Message-----
From: Mark Brown <>
Sent: Tuesday, May 5, 2020 5:21 PM
To: Agrawal, Akshu <>
Cc: RAVULAPATI, VISHNU VARDHAN RAO <>; Liam Girdwood <>; Jaroslav Kysela <>; Takashi Iwai <>; Mukunda, Vijendar <>; Colin Ian King <>; Kuninori Morimoto <>; moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM... <>; open list <>
Subject: Re: [PATCH] ASoC: amd :High hw_level while simultaneous capture

On Tue, May 05, 2020 at 05:10:20PM +0530, Akshu Agrawal wrote:

> Simultaneous capture on dmic and headset mic is having issue with high 
> hw_level being reported.

> Issue Can be reproduced by:
> arecord -D hw:2,0 -f dat -d 60 /tmp/test0 & arecord -D hw:2,2 -f dat 
> -d 60 /tmp/test1 & cat /proc/asound/card2/pcm?c/sub0/status

What is a "high hw_level" and how does this patch address it?  As far as I can see this patch reorders some of the initialzation but it's not entirely obvious what the issue was or how this fixes it.

Actual issue is :
When we open one capture stream on one instance lets say I2S_SP and then once again if we open other capture on other instance lets say I2S_BT while first capture is in progress and when we try to read the status of both running instances by below command cat /proc/asound/card2/pcm?c/sub0/status
we observe that avail_max is being doubled on first opened capture(I2S_SP in the example).

This is because our previous implementation was like when any instance is opened it gets initialized in dma_open irrespective of on what instance it called open.
For example:
First I2S_SP called opened it initializes both SP/BT capture streams irrespective of on which instance the stream time I2S_BT called opened and it initializes both SP/BT this corrupts the behaviour .

So with this patch the stream gets initialized only on specific instance when ever it gets opened calls hw_params.

This rectifies the issue.


Powered by blists - more mailing lists