Re: [PATCH 0/2] ASoC: add N cpus to M codecs dai link support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 07, 2023 at 01:13:49PM -0500, Pierre-Louis Bossart wrote:
> On 6/7/23 12:18, Mark Brown wrote:
> > On Wed, Jun 07, 2023 at 05:05:20PM +0000, Charles Keepax wrote:
> >> On Wed, Jun 07, 2023 at 05:22:45PM +0100, Mark Brown wrote:
> >> CPU A -> CODEC A
> >> CPU B -> CODEC B
> > 
> >> What makes this a single DAI link, rather than 2 DAI links? And
> >> does the information within the DAI link about what is connected
> >> to what not just start looking like DAI links?
> > 
> > Ah, indeed.  My expectation would be that for things on the same
> > physical set of wires we'd at some point be able to get to a point where
> > the the SoundWire routing would be exposed to userspace for control,
> > probably at the point where we get digital routing working (whenever in
> > the far far future that might be, it's only been a bit more than a
> > decade thus far).  I have to say Pierre's example looked like two
> > separate buses.
> 
> They are separate buses indeed at the hardware level, and even on the
> Linux side we have one manager device per link.
> 
> The key point is that all buses are synchronized with a common hardware
> signal, typically 4kHz, on the SOC/PCH side.
> 
> The dailink .trigger is translated as a multi-link bank switch which
> will start transmission exactly at the same time on all links.
> 
> That's the big difference with using multiple dailinks, if we had one
> dailink per physical pair of (clock, data) wires, we would not be able
> to synchronize amplifiers, leading to random phase offsets between
> amplifiers. Not so good.

Indeed, not so good. I had a chat with Richard and we were wonder
if this is really one of those we have started down a path and it's
a bit late to change course now situations. I don't think either
of us have a great objection to the within the DAI link hook up
table really, just hard to get my head around what a DAI link
means in that case. I guess if I just think of DAI links as being
more a logical grouping, that is being treated as a single stream,
rather than representing physical links?

To provide the other side, in my head, where most things are
C2C links rather than DPCM, the situation really looks something
like this:

            +----------+     +---------+
            +    SDW A + <-> + CODEC A +
+-----+     +          +     +---------+
+ CPU + <-> + DSP      +
+-----+     +          +     +---------+
            +    SDW B + <-> + CODEC B +
            +----------+     +---------+

And the responsibility for starting the bank switch would lie with
the DSP driver. It gets a single trigger from its DAI to the CPU,
which provides the sync point. But this seems fairly removed from
how things are presently implemented and it perhaps feels like
the effort to get there isn't worth it, especially since me and
Richard are unlikely to have the time in the near term to do a
lot of it.

Thanks,
Charles



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux