On Tue, Mar 05, 2019 at 01:42:32PM +0900, Takashi Sakamoto wrote:
Hi,
On Mon, Mar 04, 2019 at 11:59:52AM -0500, Sven Van Asbroeck wrote:
Negotiation seems to work ok, but bclk_ratio is exposed to userspace via snd_pcm_hw_params, which is not acceptable.
Constrain bclk_ratio by:
- cpu dai capabilities && rules
- codec dai capabilities && rules
- minimum bclk_ratio is sample_width * channels
In hw_params_choose(), pick the smallest supported bclk_ratio, which should correspond to the most efficient solution.
If cpu and codec dais do not specify or constrain supported bclk_ratios, alsa will pick sample_width * channels.
Signed-off-by: Sven Van Asbroeck TheSven73@gmail.com
include/sound/pcm.h | 11 +++++++++++ include/sound/soc.h | 2 ++ include/uapi/sound/asound.h | 5 +++-- sound/core/pcm_native.c | 34 +++++++++++++++++++++++++++++++++- sound/soc/soc-pcm.c | 8 ++++++++ 5 files changed, 57 insertions(+), 3 deletions(-)
In UAPI of Linux sound subsystem, sample formats are represented in enumerators prefixed with 'SNDRV_PCM_FORMAT_'. In the enumerators, sample bits and padding bits are represented:
S8 S16 S20 S24 S32 S18_3 S20_3 S24_3sample-bits: 8 16 20 24 32 18 20 24 (=width) padding-bits: 0 0 12 8 0 6 12 0 total bits: 8 16 32 32 32 24 24 24 (=physical_width)
When indicating a certain bit ratio of BCLK/WS from userspace, applications use correct combination of the above format (=physical_width) and the number of samples per audio data frame (=channels).
You seem to be conflating the in-memory format with the on-wire format. These are two entirely different things. Your table above clearly shows the in-memory format, not the on-wire format.