On 8/13/20 3:45 AM, Takashi Iwai wrote:
On Thu, 13 Aug 2020 10:36:57 +0200,
Yu-Hsuan Hsu wrote:
Lu, Brent <brent.lu@xxxxxxxxx> 於 2020年8月13日 週四 下午3:55寫道：
CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
buffer as possible. So the period size is an arbitrary number in
different platforms. Atom SST platform happens to be 256, and CML
SOF platform is 1056 for example.
ok, but earlier in this thread it was mentioned that values such as
432 are not suitable. the statement above seems to mean the period
actual value is a "don't care", so I don't quite see why this specific
patch2 restricting the value to 240 is necessary. Patch1 is needed for
sure,
Patch2 is where Takashi and I are not convinced.
I have downloaded the patch1 but it does not work. After applying patch1,
the default period size changes to 320. However, it also has the same issue
with period size 320. (It can be verified by aplay.)
The period_size is related to the audio latency so it's decided by application
according to the use case it's running. That's why there are concerns about
patch 2 and also you cannot find similar constraints in other machine driver.
You're right. However, the problem here is the provided period size
does not work. Like 256, setting the period size to 320 also makes
users have big latency in the DSP ring buffer.
localhost ~ # aplay -Dhw:1,0 --period-size=320 --buffer-size=640
/dev/zero -d 1 -f dat --test-position
Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000
Hz, Stereo
Suspicious buffer position (1 total): avail = 0, delay = 2640, buffer = 640
Suspicious buffer position (2 total): avail = 0, delay = 2640, buffer = 640
Suspicious buffer position (3 total): avail = 0, delay = 2720, buffer = 640
...
It means that the delay value returned from the driver is bogus.
I suppose it comes pcm_delay value calculated in sst_calc_tstamp(),
but haven't followed the code closely yet. Maybe checking the debug
outputs can help to trace what's going wrong.
the problem is really that we add a constraint that the period size be a
multiple of 1ms, and it's not respected. 320 samples is not a valid
choice, I don't get how it ends-up being selected? there's a glitch in
the matrix here.
