[BUG][TGL][v7.0-rc10]Wov will repeat about 1~2s of the end of recorded file #3189
Comments
Liviali155
added
bug
|
Error also can be reproduced with kernel https://github.com/thesofproject/linux/tree/tgl-007-20200716 and Firmware:https://github.com/thesofproject/sof/commits/releases/tgl/v7.0-rc10 |
|
Error only occurred when stop capture via CTRL+C, error not occurred if run and stop stream via -d 10, |
|
Hi @mrajwa this issue can be reproduced with 98357a machine on S0 also, please try it more times(3~5 times) to reproduce it. |
|
To be clarified with the Chrome team, if forceful stopping of the pipeline is to be supported. |
|
On JSL Chromebook with codec da7219max98360a in i2s mode also has this issue https://github.com/thesofproject/linux/commits/topic/sof-dev(797eb03a) |
|
When the user forcefully stops the pipeline during draining, the flow of data is aborted. There's no likely scenario that could cause the firmware to keep sending repeating data afterwards. I would recommend verifying the way the buffer read in the driver. |
|
@ranj063 can we ask for SOF driver expertise? The initial FW debug indicate problem at driver/kernel layer |
|
@ranj063, FW pipeline is stopped but yet application gets additional data - clearly layers above FW copy more than they should. |
|
This is the application bug I have already submitted patches to ALSA, @lgirdwood I think we can close it. |
|
Thanks for spotting this and providing solution, it is really nice catch! I added some comments about refining the PR alsa-project/alsa-utils#51, @perexg can you help to take a look? |
slawblauciak
added
the
Fix confirmed
|
Will close when the PR gets merged. |
This patch changes the logic of pcm_readv() when abort signal has been detected. During such condition we should return the amount of frames actually read instead of the size requested by caller. Currently functions pcm_read() and pcm_readv() when aborted (in_aborting flag set) return the amount of requested frames instead of those actually read prior to interrupt. The consequence of this is repetition of recent X frames where X stands for amount of frames in one period. This problem is barely visible or rather audible when the period is small like few milliseconds because repetition of 1 [ms] of data is not-noticeable however if we use buffer and period sizes in seconds then the problem becomes apparent. Example issue -> thesofproject/sof#3189 Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com>
This patch changes the logic of pcm_readv() when abort signal has been detected. During such condition we should return the amount of frames actually read instead of the size requested by caller. Currently functions pcm_read() and pcm_readv() when aborted (in_aborting flag set) return the amount of requested frames instead of those actually read prior to interrupt. The consequence of this is repetition of recent X frames where X stands for amount of frames in one period. This problem is barely visible or rather audible when the period is small like few milliseconds because repetition of 1 [ms] of data is not-noticeable however if we use buffer and period sizes in seconds then the problem becomes apparent. Example issue -> thesofproject/sof#3189 Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
|
PR on alsa-utils has been merged, can we close it now? |
yes, think so, thanks for proceeded it. |
This patch changes the logic of pcm_readv() when abort signal has been detected. During such condition we should return the amount of frames actually read instead of the size requested by caller. Currently functions pcm_read() and pcm_readv() when aborted (in_aborting flag set) return the amount of requested frames instead of those actually read prior to interrupt. The consequence of this is repetition of recent X frames where X stands for amount of frames in one period. This problem is barely visible or rather audible when the period is small like few milliseconds because repetition of 1 [ms] of data is not-noticeable however if we use buffer and period sizes in seconds then the problem becomes apparent. Example issue -> thesofproject/sof#3189 Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Describe the bug
Wov will repeat about 1~2s of the end of recorded file
To Reproduce
1."sudo reboot" to reboot system
2.arecord -Dhw:0,100 -M -N -f s32_le -r 16000 -i -vvv -c2 --buffer-size=96000 ./tmp.wav
Reproduce Rate
1/3
Expected behavior
Recorded file normal
Impact
Wov will repeat about 1~2s of the end of recorded file
Environment
Kernel:https://github.com/keyonjie/linux/commits/keyon-002(commit:082d5f6f2334824388b2e80de98e1f501106b756)
Firmware:https://github.com/thesofproject/sof/commits/releases/tgl/v7.0-rc10 ,(commit: fb801c8)
TPLG:sof-tgl-max98373-rt5682.tplg
Platform:Chromebook with codec 98373 in I2S mode.
dmesg0715.log
sof-logger0715.log
tmp.zip
The text was updated successfully, but these errors were encountered: