Re: ASoc: soc_core.c stream direction from snd_soc_dai

[Matt Flax <flatmax@flatmax.org>]

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.

Matt


> My 2 cents
> -Pierre