noise when switch aplay between background & foreground.

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

@Jiangxinx

@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

@lgirdwood

@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?

This issue can also be reproduced on Yorp.

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.

@bardliao

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

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

@plbossart

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

@lgirdwood

@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.

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.

@bardliao

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

@slawblauciak

@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.

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?

…

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

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.

@slawblauciak

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.

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

@mengdonglin

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

Navigation Menu

Repository navigation

noise when switch aplay between background & foreground. #574

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

noise when switch aplay between background & foreground. #574

Description

Activity

lgirdwood commented on Nov 14, 2018

mengdonglin commented on Nov 15, 2018

keqiaozhang commented on Nov 16, 2018

bardliao commented on Nov 16, 2018

lgirdwood commented on Nov 16, 2018

plbossart commented on Nov 16, 2018

bardliao commented on Nov 19, 2018

6 remaining items

bardliao commented on Nov 20, 2018

mengdonglin commented on Nov 20, 2018

lgirdwood commented on Nov 20, 2018

keqiaozhang commented on Dec 18, 2018

plbossart commented on Dec 18, 2018

slawblauciak commented on Dec 18, 2018

bardliao commented on Dec 18, 2018

wenqingfu commented on Dec 19, 2018

mengdonglin commented on Dec 19, 2018

lgirdwood commented on Dec 19, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions