[alsa-devel] Multiple codecs on the same DAI
Hi,
I'm studying a hardware implementation where an S/PDIF receiver is on the same I2S connection as codec. Essentially, the S/PDIF receiver echos the I2S capture data from the codec unless there is a digital input signal which it can lock on to. For playback, the I2S output from the CPU DAI goes directly to the codec.
I'm a bit at a loss for how to model this in ALSA. I know it's possible to have multiple codecs on a card, but those cases seem to be either separate codecs for the left and right channels, or separate codecs for capture and playback. In my case the playback codec is always the same, but the capture codec can switch between the two avilable input methods (more or less automatically if the S/PDIF receiver is so configured).
From a user perspective, it's not important that ALSA knows where the data
is actually coming from, so if I could just register the two "codecs" on the same dai_link at the same time it would be fine, but I'm just imagining that I'll run into problems when ALSA tries to set up streams with two different codecs being involved. (Of course, at some level, the user might be interested to know the signal routing, but that can be determined by reading appropriate status bits in the S/PDIF receiver for instance using amixer controls).
Do you have any ideas about how to configure this in ALSA?
/Ricard
On Thu, Nov 23, 2017 at 03:51:19PM +0100, Ricard Wanderlof wrote:
I'm studying a hardware implementation where an S/PDIF receiver is on the same I2S connection as codec. Essentially, the S/PDIF receiver echos the I2S capture data from the codec unless there is a digital input signal which it can lock on to. For playback, the I2S output from the CPU DAI goes directly to the codec.
I take it this is a TDM setup?
I'm a bit at a loss for how to model this in ALSA. I know it's possible to have multiple codecs on a card, but those cases seem to be either separate codecs for the left and right channels, or separate codecs for capture and playback. In my case the playback codec is always the same, but the capture codec can switch between the two avilable input methods (more or less automatically if the S/PDIF receiver is so configured).
The capture CODEC is the problem here. If we had digital domain stuff working well then we could model this easily enough by showing a loopback within the S/PDIF chip but that's not there yet. As it is it sounds like the easiest thing is just going to be to ignore the S/PDIF CODEC in software and fudge things by telling the SoC to read the TDM slot that it is sending on. That way the regular CODEC will get set up normally and the S/PDIF device can transparently handle the switching.
On Fri, 24 Nov 2017, Mark Brown wrote:
On Thu, Nov 23, 2017 at 03:51:19PM +0100, Ricard Wanderlof wrote:
I'm studying a hardware implementation where an S/PDIF receiver is on the same I2S connection as codec. Essentially, the S/PDIF receiver echos the I2S capture data from the codec unless there is a digital input signal which it can lock on to. For playback, the I2S output from the CPU DAI goes directly to the codec.
I take it this is a TDM setup?
No, it is not.
The S/PDIF receiver chip contains a mux, that switches between the capture data generated by the codec and the decoded S/PDIF data. By default, the chip automatically switches over from echoing the codec data to the decoded S/PDIF data when valid S/PDIF data is present, and back to the codec data when S/PDIF lock is lost.
So what comes out of the conglomeration is standard stereo I2S, which has originated either from the codec or the S/PDIF receiver. Furthermore, the S/PDIF receiver generates the clocking for the codec (using either the clock derived from the incoming S/PDIF signal, or an internal crystal oscillator), so it can (and does apparantly, looking at the signals on a 'scope) more or less seemlessly segue between the two sources.
The capture CODEC is the problem here. If we had digital domain stuff working well then we could model this easily enough by showing a loopback within the S/PDIF chip but that's not there yet. As it is it sounds like the easiest thing is just going to be to ignore the S/PDIF CODEC in software and fudge things by telling the SoC to read the TDM slot that it is sending on. That way the regular CODEC will get set up normally and the S/PDIF device can transparently handle the switching.
What I've done so far is to ignore the S/PDIF chip, and that approach works well to start with, but I'd really like to link it into the machine driver somehow, so that any ALSA controls for the S/PDIF receiver can be exposed as being part of the same sound card as the codec. I haven't tried adding the S/PDIF receiver into the dai_link in my snd_soc_card as I think that would problematic for instance since the S/PDIF receiver only supports capture, not playback.
In a sense, what I'd want would be to bring in the S/PDIF receiver as a codec driver, but separate from the ordinary chain of sound drivers (codec, platform, etc). I suppose one way would be to somehow (via platform data or DT) pass a reference to the S/PDIF receiver to the machine driver, which would then somehow convert this to a snd_soc_codec *, and then have it explicitly call the the snd_soc_codec_driver.probe function set up by the S/PDIF receiver driver to initialize it much the way ALSA would have done if it had been part of a dai_link for card.
/Ricard
On Fri, Nov 24, 2017 at 03:21:24PM +0100, Ricard Wanderlof wrote:
In a sense, what I'd want would be to bring in the S/PDIF receiver as a codec driver, but separate from the ordinary chain of sound drivers (codec, platform, etc). I suppose one way would be to somehow (via platform data or DT) pass a reference to the S/PDIF receiver to the machine driver, which would then somehow convert this to a snd_soc_codec *, and then have it explicitly call the the snd_soc_codec_driver.probe function set up by the S/PDIF receiver driver to initialize it much the way ALSA would have done if it had been part of a dai_link for card.
You can just register any CODEC device as an aux_dev, that seems to be exactly what you're looking for.
On Fri, 24 Nov 2017, Mark Brown wrote:
On Fri, Nov 24, 2017 at 03:21:24PM +0100, Ricard Wanderlof wrote:
In a sense, what I'd want would be to bring in the S/PDIF receiver as a codec driver, but separate from the ordinary chain of sound drivers (codec, platform, etc). I suppose one way would be to somehow (via platform data or DT) pass a reference to the S/PDIF receiver to the machine driver, which would then somehow convert this to a snd_soc_codec *, and then have it explicitly call the the snd_soc_codec_driver.probe function set up by the S/PDIF receiver driver to initialize it much the way ALSA would have done if it had been part of a dai_link for card.
You can just register any CODEC device as an aux_dev, that seems to be exactly what you're looking for.
Ah, thanks. Yes, having tried it now it does indeed seem to be what I need.
How about non-sound devices, for instance if there is a chip solely for managing the microphone power but it's not actually part of the codec. Is it reasonable to bring it in as an aux device too, even though there's actually no sound going through it?
/Ricard
On Wed, Dec 06, 2017 at 01:54:38PM +0100, Ricard Wanderlof wrote:
How about non-sound devices, for instance if there is a chip solely for managing the microphone power but it's not actually part of the codec. Is it reasonable to bring it in as an aux device too, even though there's actually no sound going through it?
That just sounds like a regulator? I'd expect that just to be used as a supply as normal. What audio specific control would this device be provdiing?
On Wed, 6 Dec 2017, Mark Brown wrote:
On Wed, Dec 06, 2017 at 01:54:38PM +0100, Ricard Wanderlof wrote:
How about non-sound devices, for instance if there is a chip solely for managing the microphone power but it's not actually part of the codec. Is it reasonable to bring it in as an aux device too, even though there's actually no sound going through it?
That just sounds like a regulator? I'd expect that just to be used as a supply as normal.
You mean as a DAPM widget?
What audio specific control would this device be provdiing?
What it does provide is current sensing if the connected device draws too much power, although it does not automatically shut off the connected device if that is the case, so a small driver is required to shut down the output in the case of overcurrent. There's also a requirement to be able to read the overcurrent status. One approach is to implementet the whole thing as an auxilliary device, with one ALSA control to control the power, and a read only control to read the overcurrent status.
So, no, it's not really audio specific, and furthermore it's not just providing a power output the way a regulator would.
It could of course be implemented as a completely separate device, but hardware wise it is still an integrated part of the audio solution.
/Ricard
On Wed, Dec 06, 2017 at 03:26:47PM +0100, Ricard Wanderlof wrote:
On Wed, 6 Dec 2017, Mark Brown wrote:
That just sounds like a regulator? I'd expect that just to be used as a supply as normal.
You mean as a DAPM widget?
Or via a device which uses it.
What audio specific control would this device be provdiing?
What it does provide is current sensing if the connected device draws too much power, although it does not automatically shut off the connected device if that is the case, so a small driver is required to shut down the output in the case of overcurrent. There's also a requirement to be able to read the overcurrent status. One approach is to implementet the whole thing as an auxilliary device, with one ALSA control to control the power, and a read only control to read the overcurrent status.
That does sound like an auxiliary device that's a regulator consumer.
On Wed, 6 Dec 2017, Mark Brown wrote:
On Wed, Dec 06, 2017 at 03:26:47PM +0100, Ricard Wanderlof wrote:
On Wed, 6 Dec 2017, Mark Brown wrote:
That just sounds like a regulator? I'd expect that just to be used as a supply as normal.
You mean as a DAPM widget?
Or via a device which uses it.
What audio specific control would this device be provdiing?
What it does provide is current sensing if the connected device draws too much power, although it does not automatically shut off the connected device if that is the case, so a small driver is required to shut down the output in the case of overcurrent. There's also a requirement to be able to read the overcurrent status. One approach is to implementet the whole thing as an auxilliary device, with one ALSA control to control the power, and a read only control to read the overcurrent status.
That does sound like an auxiliary device that's a regulator consumer.
So essentially one would register this device as an auxiliary device, which would define a DAPM widget which in turn would be part of a DAPM route in the encompassing machine driver?
/Ricard
On Thu, Dec 07, 2017 at 08:47:03AM +0100, Ricard Wanderlof wrote:
On Wed, 6 Dec 2017, Mark Brown wrote:
That does sound like an auxiliary device that's a regulator consumer.
So essentially one would register this device as an auxiliary device, which would define a DAPM widget which in turn would be part of a DAPM route in the encompassing machine driver?
Or register a device that consumes the regulator and maps it into ASoC like that.
On Thu, 7 Dec 2017, Mark Brown wrote:
On Thu, Dec 07, 2017 at 08:47:03AM +0100, Ricard Wanderlof wrote:
On Wed, 6 Dec 2017, Mark Brown wrote:
That does sound like an auxiliary device that's a regulator consumer.
So essentially one would register this device as an auxiliary device, which would define a DAPM widget which in turn would be part of a DAPM route in the encompassing machine driver?
Or register a device that consumes the regulator and maps it into ASoC like that.
Do you offhand know of an example of such an external regulator implementation in the soc tree that I could look at to see how it all fits together?
/Ricard
On Thu, Dec 07, 2017 at 12:31:12PM +0100, Ricard Wanderlof wrote:
On Thu, 7 Dec 2017, Mark Brown wrote:
Or register a device that consumes the regulator and maps it into ASoC like that.
Do you offhand know of an example of such an external regulator implementation in the soc tree that I could look at to see how it all fits together?
No. I honestly can't think of any such hardware that I've ever seen - current sensing microphone biases I've seen have all been integrated into a CODEC.
participants (2)
-
Mark Brown -
Ricard Wanderlof