lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Aug 2020 07:55:43 +0000
From:   "Lu, Brent" <>
To:     Yu-Hsuan Hsu <>,
        Pierre-Louis Bossart <>
CC:     Takashi Iwai <>,
        Guennadi Liakhovetski <>,
        "" <>,
        Andy Shevchenko <>,
        Kuninori Morimoto <>,
        Kai Vehmanen <>,
        "" <>,
        "Rojewski, Cezary" <>,
        Jie Yang <>,
        "Takashi Iwai" <>,
        Liam Girdwood <>,
        "Sam McNally" <>,
        Mark Brown <>,
        "Ranjani Sridharan" <>,
        Daniel Stuart <>,
        "" <>,
        Damian van Soelen <>
Subject: RE: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago

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

Another problem is the buffer size. Too large buffer is not just wasting memories.
It also creates problems to memory allocator since continuous pages are not
always there. Using a small period_count like 2 or 4 should be sufficient for audio
data transfer.

buffer_size = period_size * period_count * 1000000 / sample_rate;
snd_pcm_hw_params_set_buffer_time_near(mPcmDevice, params, &buffer_size, NULL);

And one more problem here: you need to decide period_size and period_count
first in order to calculate the buffer size...


Powered by blists - more mailing lists