Re: ASoc: soc_core.c stream direction from snd_soc_dai

[Matt Flax <flatmax@flatmax.org>]

On 13/3/20 10:19 am, Matt Flax wrote:
>
> On 13/3/20 9:55 am, Pierre-Louis Bossart wrote:
>>
>>
>> On 3/11/20 5:54 PM, Matt Flax wrote:
>>> Hi there,
>>>
>>> A large number of audio codecs allow different formats for playback 
>>> and capture. This becomes very useful when there are different 
>>> latencies between playback and capture hardware data lines. For 
>>> example digital isolation chips typically have a 1 bit delay in 
>>> propagation as the bit clock rate gets faster for higher sample 
>>> rates. By setting the capture and playback formats to differ by one 
>>> or two bit clock cycles, the delay problem is solved.
>>>
>>> There doesn't seem to be a simple way to detect stream direction in 
>>> the codec driver's set_fmt function.
>>>
>>> The snd_soc_runtime_set_dai_fmt function :
>>>
>>> https://github.com/torvalds/linux/blob/master/sound/soc/soc-core.c#L1480 
>>>
>>>
>>> calls the snd_soc_dai_set_fmt function :
>>>
>>> https://github.com/torvalds/linux/blob/master/sound/soc/soc-dai.c#L101
>>>
>>> which calls the set_fmt function :
>>>
>>> https://github.com/torvalds/linux/blob/master/include/sound/soc-dai.h#L189 
>>>
>>>
>>>
>>> The snd_soc_dai_ops set_fmt function is defined as :
>>>
>>>      int (*set_fmt)(struct snd_soc_dai *dai, unsigned int fmt);
>>>
>>>
>>> Is there a simple way to find the stream direction from a snd_soc_dai ?
>>>
>>> If the stream direction can be detected then the playback and 
>>> capture formats can be set independently for the codec.
>>>
>>> It there a different way to set the playback and capture formats for 
>>> the codec independently at runtime, depending on the sample rate ?
>>
>> FWIW I remember a discussion in the past on how to deal with 
>> interfaces that may have different clocks sources for capture and 
>> playback (typically with the 6-pin version of I2S/TDM), and the 
>> answer was: use two dais, with one dealing with capture and the other 
>> with playback.
>>
>> I would bet this applies for the format as well. If you use a DAI 
>> that can do both directions, then indeed there's no obvious way to 
>> specify that formats or clock ownership could be different between 
>> the two directions.
>>
>> It would probably make sense anyway to have a representation with two 
>> dais, e.g. the codec capture dai receives data from somewhere and the 
>> codec playback dai forwards it to another destination.
>>
> I think I get it ...
>
> This approach would keep extra stream selective functionality out of 
> soc-dai.c. That is probably a good thing for the simplicity of the core.
>
> A machine driver could then call snd_soc_dai_set_fmt passing in the 
> correct codec_dai from the codec_dais array for the stream they want 
> to operate on.
>
In an example case, cs4271 ... how do we enforce symmetric rates ?

static struct snd_soc_dai_driver cs4271_dai[] = {
     {
         .name = "cs4271-hifi-p",
         .playback = {
             .stream_name    = "Playback",
             .channels_min    = 2,
             .channels_max    = 2,
             .rates        = CS4271_PCM_RATES,
             .formats    = CS4271_PCM_FORMATS,
         },
         .ops = &cs4271_dai_ops,
         .symmetric_rates = 1,
     },
     {
         .name = "cs4271-hifi-c",
         .capture = {
             .stream_name    = "Capture",
             .channels_min    = 2,
             .channels_max    = 2,
             .rates        = CS4271_PCM_RATES,
             .formats    = CS4271_PCM_FORMATS,
         },
         .ops = &cs4271_dai_ops,
         .symmetric_rates = 1,
     }
};



> Matt
>
>
>> My 2 cents
>> -Pierre