Re: How to handle stream rates if CPU supports many channels ?

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

On 2017年06月06日 09:48, Kuninori Morimoto wrote:
> Basic use case of my CPU driver is 2ch output,
> but, it can handle 6ch, 8ch, 16ch sounds.
> And it can be clock master.
> 
> In this case, for example, if CPU has 12288000 system clock
> and it uses 32bit for each 1ch data (it has divider inside).
> 
> 	Max 2ch sound Hz = 12288000 / 32 / 2 = 192000Hz
> 	Max 8ch sound Hz = 12288000 / 32 / 8 =  48000Hz
> 
> If my understanding was correct, struct snd_soc_pcm_stream::rates
> is needed when sound device "open" timing
> (= struct snd_soc_dai_ops::startup), but, we can receive used
> channels number when "hw_params" timing ?
> 
> My question is that if system has 12288000, and if it can
> support both 2ch and 8ch, what struct snd_soc_pcm_stream::rates
> should have ??
> 	SNDRV_PCM_RATE_8000_192000 ?
> 	SNDRV_PCM_RATE_8000_48000  ?

If your hardware support the two modes for PCM frame transmission, you 
need to describe it correctly into runtime of PCM substream for ALSA PCM 
application. No matter whether the driver is in ALSA SoC part or not.

In design of ALSA PCM interface, PCM runtime get constraints and rules 
of parameters when applications execute open(2) to ALSA PCM character 
device. In this timing, drivers should register the constraints and the 
rules in callbacks of 'struct snd_pcm_ops.open'.

Your CPU driver should register them in callback of 'struct 
snd_soc_dai.startup()' in a callgraph from open(2). For example with 
code snippet:

```
static int hw_rule_rate()
{
unsigned int list[2]
/* when the range of channels include 2, then 192000 is available. */
/* when the range of channels include 8, then 48000 is available. */
snd_interval_list(list)
}

static int hw_rule_channels()
{
unsigned int list[2]
/* when the range of rates include 48000, then 8ch is available. */
/* when the range of rates include 192000, then 2ch is available. */
snd_interval_list(list)
}

static int startup()
{
...
snd_pcm_hw_rule_add(SNDRV_PCM_HW_PARAM_RATE, hw_rule_rate, 
SNDRV_PCM_HW_PARAM_CHANNELS)
snd_pcm_hw_rule_add(SNDRV_PCM_HW_PARAM_CHANNELS, hw_rule_channels, 
SNDRV_PCM_HW_PARAM_RATE)
...
}

struct snd_soc_dai.startup = startup;
```

Furthermore, PCM runtime require constraints for channels and rates. In 
ALSA SoC part, this is done by 'soc_pcm_init_runtime_hw()' in 
'sound/soc/soc-pcm.c'. Your driver should have proper values in data of 
'struct snd_soc_pcm_stream' as the constraints.

```
(struct snd_soc_dai_driver.playback or capture?)
struct snd_soc_pcm_stream.channels_min = 2
struct snd_soc_pcm_stream.channels_max = 8
struct snd_soc_pcm_stream.rate_min = 48000
struct snd_soc_pcm_stream.rate_max = 192000
struct snd_soc_pcm_stream.rates =
     SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_192000
```

When implement these correctly, userspace applications can get enough 
information about PCM substream for your hardware by executing ioctl(2) 
with HW_REFINE/HW_PARAMS. If you need more combination between channels 
and rates, please expand these basic codes as you like. If you need some 
examples, please investigate drivers outside of ALSA SoC part.


Regards

Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel