[TEST] Do not merge: use demux for synchronize playback

[bardliao]

I am trying to create a topology for synchronize playback on different links.
It will look like

PCM2P -> BUF3.0 -> PGA3.1 -> BUF3.1 ->  MUXDEMUX3.0 -+-> BUF3.2 -> ALH0x102.OUT
                                                     |
                                                     +-> BUF3.3 -> ALH0x202.OUT

[lgirdwood]

@bardliao I assume both ALH DAIs have the same rate and same clock domain ?
You will also need to add a tuple in the topology so that we can associate these two DAIs together for triggering purposes (to sync the start). e.g.

TUPLE_DAI_SYNC_TRIGGER   "ALHDAI1"

This will need define multiple time for each DAI that is connected.

You will also need to add logic to dai.c that will delay triggering a connected DAI (until all DAIs are ready) then trigger all in one operation.

[bardliao]

@bardliao I assume both ALH DAIs have the same rate and same clock domain ?

Yes, they are identical.

You will also need to add a tuple in the topology so that we can associate these two DAIs together for triggering purposes (to sync the start). e.g.

TUPLE_DAI_SYNC_TRIGGER   "ALHDAI1"

This will need define multiple time for each DAI that is connected.

You will also need to add logic to dai.c that will delay triggering a connected DAI (until all DAIs are ready) then trigger all in one operation.

Thanks @lgirdwood for the instruction. The issue I meet is that somehow there is no output from ALH0x202. In fact, I think there is no data on BUF3.3 but I didn't verify it. Currently, demux is restricted to use two different pipeline. So maybe we need to modify demux to support this scenario first.

[lgirdwood]

Thanks @lgirdwood for the instruction. The issue I meet is that somehow there is no output from ALH0x202. In fact, I think there is no data on BUF3.3 but I didn't verify it. Currently, demux is restricted to use two different pipeline. So maybe we need to modify demux to support this scenario first.

I would expect the demux to write to buf 3.3 and buf 3.2 for every copy invocation. Have you checked the demux runtime kconfig ? It could be one output is disabled by a kcontrol.

[bardliao]

I would expect the demux to write to buf 3.3 and buf 3.2 for every copy invocation. Have you checked the demux runtime kconfig ? It could be one output is disabled by a kcontrol.

No, that is byte control. Is there a tool to check/configure it? BTW, I was told that the first item of 0x01,0x00,0x00,0x00,0x02,0x01,0x02,0x04 and 0x05,0x00,0x00,0x00,0x02,0x01,0x02,0x04, (0x01 and 0x05) are the pipeline which are connected to the demux. But I will get ipc error if I change them to 0x03 and 0x03.
I didn't get any output from sof-logger, but I believe that the error is mux_set_values() error: multiple configured streams have same pipeline ID = %u

[lgirdwood]

@bardliao is there userspace tooling for the demux. @akloniex @jajanusz @tlauda @ktrzcinx any comment on the tooling ?

[juimonen]

@lgirdwood no there isn't. I have have my own tool in my own machine....

I understood, that the situation is that we should be moving to use the channel map in demux and get rid of var arrays in ipc/fw -> and move to tuples in tplg, so no blob/tool would be needed. So I don't know what should be the best thing to do now...?

[lgirdwood]

@juimonen what's blocking the channel map updates ? Do they have any merge blockers ?

[juimonen]

@lgirdwood I have not followed the FW side on this... @fkaczmar is someone on FW side working on mux/demux? I understood there are some changes on the way?

[lgirdwood]

@juimonen so are you saying the driver side is ready but FW side is not ?

[juimonen]

@lgirdwood probably not.

1. I just have currently impression (maybe a false one) that someone on fw side is going to do changes to demux for it to use channel map. I'm not sure is someone working on this or is it already done.

2. I think I recall promising to change the kernel side if needed. I've done rfc PR to use the channel map with tokens (not binary blob) for demux configuration. So I was kind of assuming that someone will do the FW counterpart.

3. Third there's Pierre's effort of removing the var arrays from ipc. Current channel maps don't take this into account and thus not my rfc PR either. But if the array size is fixed the PR's will actually come simpler.

[bardliao]

@juimonen @lgirdwood We may not need channel map for the synchronize playback feature. We will send identical data to all DAIs. @tlauda gave me some suggestion on the topology part. I will try it tomorrow.

[bardliao]

Replaced by #2526