Dne 08. 03. 19 v 18:22 Mark Brown napsal(a): > On Fri, Mar 08, 2019 at 12:59:16PM +0000, Russell King - ARM Linux admin wrote: >> On Fri, Mar 08, 2019 at 01:10:57PM +0900, Takashi Sakamoto wrote: > >>> In expectation of ALSA PCM interface for hardware for usual device: >>> - half number of phases of SCK per phase of WC >>> = physical_width of sample >>> = bytes per sample > >> They are not the same thing. > >> Let's take SNDRV_PCM_FORMAT_S16_LE. The in-memory layout of this format >> is two 16-bit samples next to each other in a single 32-bit word. Their >> width is 16, their physical_width is 16, and bytes per sample is 2. > >> A CPU DAI can do one of two things: > >> 1) it can generate exactly 16 SCK clock cycles per sample before WS >> changes state, leading to a total of 32 SCK clock cycles per >> frame. > >> 2) it can generate more than 16 SCK clock cycles per sample. > >> Both are entirely legal and permissable under the I2S specification. >> Both look the same in memory. > >> The ALSA format specification (SNDRV_PCM_FORMAT_*) does not specify >> which of these two is used on the wire - it only specifies the in- >> memory format. > > Everything Russell is saying here is correct. The actual > ABI only affects the in memory format, userspace really shouldn't care > what's going on on the wire. However we don't have separate > infrastructure for what goes on the wire and 90% of the time you can > just translate the memory layout into a wire layout which works so we're > conflating the two in a lot of places internally which is confusing and > fragile. I agree. We just need a library which will: 1) gather the information from hardware drivers - a simple description of the bclk constrains 2) create right constraints (hw_params rules) for the ALSA PCM API 3) return the selected bclk when hw_params are installed The description of the bclk constraints from the hardware driver might be min/max or a list of allowed wire format bit width * channels, eventually define the wire formats (bitmask) and use them in this library. I can imagine that all of those bclk contraints descriptions (or any future, if there are such requirement) can be implemented in this library. The library should not extend hw_params (new interval), but it should work as a separate layer - use new structures / functions etc. Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
