On 06/04/2015 04:22 PM, Ricard Wanderlof wrote:
On Thu, 4 Jun 2015, Lars-Peter Clausen wrote:
I'm not too sure how well it works if one CODEC is playback only and the other is capture only and there might be some issues. But this is the way to go and if there are problems fix them.
It doesn't seem as if snd_soc_dai_link_component is used in any (in-tree) driver; a grep in sound/soc just returns soc-core.c . Perhaps some out-of-tree driver has been used to test it?
This is the only example I'm aware of: http://wiki.analog.com/resources/tools-software/linux-drivers/sound/ssm4567#...
Ok, thanks. As you mentioned previously this is an example of a left-right split codec configuration.
Even if your device does not have any configuration registers it will still have constraints like the supported sample rates, sample-widths, etc. You should create a driver describing these capabilities. This ensures that the driver will work when the device is connected to a host side CPU DAI that supports e.g. sample-rates outside the microphones range. The AK4554 driver is an example of such a driver.
Yes, makes sense.
An mildly interesting aspect is that the resulting device doesn't belong to anything in the device tree, it just floats around by itself, as the device tree doesn't model I2S as a bus. A minor observation, don't know if it should be done differently.
How are the different component codecs accessed when accessing the device? Or does this happen automatically? For instance, normally I would register one card with the single dai and coec, which would come up as #0, so I could access the resulting device with hw:0,0 . But when I have two codecs on the same dai_link, what mechanism does ALSA use to differentiate between the two? Or is it supposed to happen automatically depending on the capabilities of the respective codecs.
It will be exposed as a single card with one capture and one playback PCM. So it will be the same as if the CODEC side was only a single device supporting both.
Ok.
I've experimented with this.
The first problem is that the framework intersects the two codec drivers' capabilities, and since one of them supports playback only and the other capture only, the intersected rates and formats are always 0.
I've fixed this by jumping out of the loop early in soc_pcm_init_runtime_hw() if the codec in question doesn't seem to support the mode (playback vs. capture) that's being considered, indicating that it doesn't care about the rate or format for that mode.
Ideally it would have been some sort of 'if (!codec_stream->defined)' but there isn't such a member in struct snd_soc_dai . I've gone with 'if (!codec_stream->rates && !codec_stream->formats)', thinking that if a codec doesn't support any rates or formats, it probably doesn't support that mode at all (else it's rather meaningless). In fact, one of these (rates or formats) would probably suffice, with a comment explaining what we're really trying to do.
The next problem is that when trying to set hw params, something in the framework or the individual codec driver hw_params() bails out saying it can't set the intended parameters. Looking at that right now to see if it can be solved in a similar way.
The best way to solve this is probably to introduce a helper function bool snd_soc_dai_stream_valid(struct snd_soc_dai *dai, int stream) that implements the logic for detecting whether a DAI supports a playback or capture stream. And then whenever iterating over the codec_dais field for stream operations skip those which don't support the stream.
- Lars