Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> 於 2020年8月13日 週四 下午8:57寫道： > > > > 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. > > Oh sorry that I applied the wrong patch. With the correct patch, the default period size is 432. With period size 432, running aplay with --test-position does not show any errors. However, by cat `/proc/asound/card1/pcm0p/sub0/status`. We can see the delay is around 3000. Here are all period sizes I have tried. All buffer sizes are set to 2 * period size. period size: 192, delay is a negative number. Not sure what happened. period size: 240, delay is fixed at 960 period size: 288, delay is around 27XX period size: 336, delay is around 27XX period size: 384, delay is around 24XX (no errors from aplay) period size: 432, delay is around 30XX (no errors from aplay) period size: 480, delay is fixed at 3120 (no errors from aplay) period size: 524, delay is around 31XX (no errors from aplay) Not sure why the delay is around 50ms except for the period size 240. Is it normal? Thanks, Yu-Hsuan
