noise when switch aplay between background & foreground.

[Jiangxinx]

Noise when switch aplay between background & foreground.

How to reproduce:
1.aplay -Dhw:0,0 -c2 -fS16_LE audio.wav -vv -i
2.background aplay
ctrl+z
3.foreground aplay
%1
4.sof-logger -l sof-apl.ldc -t -o dsp.log

Env:
hardware version: UP2
sof-master: c05850c
soft-master: 5894ed4
kernel sof-dev: 326e446
tplg: sof-apl-pcm512x.tplg

Log:
dsp.log
dmesg.log

[lgirdwood]

@Jiangxinx can you provide audacity screenshots (with several zoom levels) of capture noise when playing a fixed frequency sine wave and also some small wav file recordings. Please also try aply with bigger buffer and more periods to see if the result is the same.

@mengdonglin please can you add a section in your howto for different types of bugs. i.e. we have boot bugs, runtime logic bugs and audio quality bugs atm

[mengdonglin]

@lgirdwood Okay. I updated the PR but missed this. I need more time to cook the type-specific guide. Probably I can revise in a later PR?

[keqiaozhang]

This issue can also be reproduced on Yorp.

[bardliao]

I noticed that the issue only happens on background/foreground switching, but not on pulse/resume. switching. Also, underrun can usually be seen on background/foreground switching. The action different between background/foreground and pulse/resume switching is that the former is STOP/START and the latter is PAUSE/RELEASE. I will check what is the different between the two actions on kernel side. It will be better if someone can check it on firmware side simultaneously.

[lgirdwood]

@bardliao I suspect XRUN handling on the kernel side here when switching. If so its's usually down to aplay userspace scheduling of IO.

[plbossart]

This isn't a bug. The time it takes between the control-Z and the bg command is typically much larger than the audio buffer, so underflows will happen.
However, what is important is that the system does not crash, so you should have a script that tests this e.g.

speaker-test -Dhw:0,0 -c2 -r48000 &
pkill -STOP speaker-test; sleep 5; pkill -CONT speaker-test

and the result shows the test continues after the underflow

speaker-test 1.1.4

Playback device is hw:0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 16384
Period size range from 32 to 8192
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
 0 - Front Left
 1 - Front Right
Write error: -32,Broken pipe
Time per period = 10.279778
 0 - Front Left
 1 - Front Right
Time per period = 5.973364
 0 - Front Left
 1 - Front Right
Write error: -32,Broken pipe
Time per period = 10.628906
 0 - Front Left
 1 - Front Right

[bardliao]

@plbossart Did you mean that the noise is not a bug? It seems xrun could muss up the data buffer.

[lgirdwood]

@bardliao XRUN handling is expected to glitch, but is also expected to quickly recover back to normal. It's a bug if playback/capture does not recover after XRUN.

[bardliao]

@lgirdwood @plbossart @slawblauciak The noise will not stop until next background/foreground switching. i.e. Playback may recover by another background/foreground switching, but not always. So, I think it is a bug. The issue can be seen on both SSP and HDMI playback.

[lgirdwood]

@bardliao no bug, backgrounded tasks don't inherit the priority of the foreground shell they spawned from. The issue here is that userspace does not schedule aplay in the background with low enough latency that it did in the foreground.

[bardliao]

@lgirdwood How about #506 ? Is it a bug? I can reproduce the issue on UP2. But if I use legacy hda driver, it works fine. ie. There is no noise on UP2 when I echo 1 to xrun_injection with legacy HDA driver. I tested with HDMI port for both SOF and legacy hda driver.

[mengdonglin]

This seems to be a issue on recovering from XRUN, and probably a duplicate of #506 .
Probably we can revisit this issue after #506 is solved.

[lgirdwood]

@bardliao not an equal comparison with legacy driver since buffers, periods, latency and pipelines are all different.

[keqiaozhang]

@slawblauciak
Could you take a look at this issue? Google also report such issue in their issue tracker.
How to reproduce:

1. speaker-test -D hw:0,0 -t sine -c 2 
2. use 'ctl-z' to suspend and 'fg' to resume.
3. Repeat step 2 

Eventually you will get an iteration where the sine wave it noticeably no longer playing the correct tune and sounds distorted.

[plbossart]

On 12/18/18 1:29 AM, Keqiao Zhang wrote: @slawblauciak <https://github.com/slawblauciak> Could you take a look at this issue? Google also report such issue in their issue tracker. How to reproduce: |1. speaker-test -D hw:0,0 -t sine -c 2 2. use 'ctl-z' to suspend and 'fg' to resume. 3. Repeat step 2 | Eventually you will get an iteration where the sine wave it noticeably no longer playing the correct tune and sounds distorted.

This creates a xrun and the driver/firmware aren't able to recover. Isn't it a known issue?

…

[slawblauciak]

Yes, it is a known issue and is being actively worked on.
See:
#710
#645

[bardliao]

It seems worse than before. It was noise when the issue is reported, but it is IPC timed out now. ie. XRUN can kill FW now.

[wenqingfu]

Yes, it is a known issue and is being actively worked on.
See:
#710
#645

@slawblauciak please check out #506 (comment) The topics you and @keyonjie are talking in the above two issues don't directly lead to a fix.

[mengdonglin]

This is a duplicater of #752, reported by Google.

[lgirdwood]

@mengdonglin duplicates should be closed to focus discussion on the correct item. I've closed this one, can you take care of other duplicates.