Multiple codecs on the same DAI

Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1391 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 769 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 494 bytes --]

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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 943 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 467 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Multiple codecs on the same DAI

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Multiple codecs on the same DAI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 523 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]