Skip to content

Conversation

@bkokoszx
Copy link
Collaborator

@bkokoszx bkokoszx commented Oct 3, 2019

Add SOF_COMP_SMART_AMP type for smart amp component.
Basic topology using smart amplifier component
could be as follows:

            +--------------------------------------------+
+------+    | +---+  +---------------+  +---+  +-------+ |
| Host |----->|Buf|->|   Smart Amp   |->|Buf|->|SSP Dai|----------+
+------+    | +---+  +---------------+  +---+  +-------+ |        |
            +----------------^---------------------------+        |
                             |                                    |
                           +---+                                  |
                           |Buf|                                  | 
                           +---+                                  |
                             ^                                    |
            +----------------|-----------------------------+      |
+------+    | +---+  +-------|---------+  +---+  +-------+ |      |
| Host |<-----|Buf|<-|      Demux      |<-|Buf|<-|SSP Dai|<-------+
+------+    | +---+  +-----------------+  +---+  +-------+ |
            +----------------------------------------------+

Basic topology contains Smart Amp component in playback pipeline and Demux
component in capture pipeline. There is a additional buffer (feedback)
between them in order to process "feedback".

Signed-off-by: Bartosz Kokoszko bartoszx.kokoszko@linux.intel.com

@bkokoszx bkokoszx requested a review from a team as a code owner October 3, 2019 09:04
@dbaluta
Copy link
Collaborator

dbaluta commented Oct 3, 2019

@bkokoszx drawing is very nice. Please include the PR description inside commit message. Otherwise, it will be lost into git PR history.

No one looks into closed PRs, every useful information should be placed inside git commit message.

@juimonen
Copy link

juimonen commented Oct 3, 2019

@bkokoszx so is the smart_amp and smart_amp_demux different components or same component with different parameters? Also do you have to possible topology (m4->alsa.conf) changes soewhere?

@bkokoszx bkokoszx force-pushed the topology-smart-amp-comp branch from aab6199 to b7c7292 Compare October 3, 2019 11:31
@bkokoszx
Copy link
Collaborator Author

bkokoszx commented Oct 3, 2019

@dbaluta
I've updated commit message.

@juimonen
Smart Amp and Smart Amp Demux are different components created by the same ipc struct (the same as we have mux and demux). I still have a doubts do we really need separate struct sof_ipc_comp_smart_amp for those components, we can
also handle them by e.g. struct sof_ipc_comp_process easily (@dbaluta @juimonen @lgirdwood what's your opinion?).
I do not have tplg file yet and to be honest I'm not an specialist at this - I will probably need some help :)

@bkokoszx
Copy link
Collaborator Author

@lgirdwood
Could you please refer to my last comment?

@xiulipan
Copy link
Contributor

xiulipan commented Oct 16, 2019

@bkokoszx @lgirdwood @plbossart Do we got a ABI version for this? As I will work on the kernel part now.

PS: what dapm comp would this smart amp mapped to? Are they sometype of mux and demux with some special config?

@bkokoszx
Copy link
Collaborator Author

@xiulipan
IMHO It could be separate component type, but I may be wrong (@lgirdwood @plbossart what do you think?).

@plbossart
Copy link
Member

yes there should be something indicating those new devices are present, but more importantly the topology ABI needs to be updated so that we can check consistency between topology and firmware.

@bkokoszx bkokoszx added the ABI ABI change involved label Oct 17, 2019
@xiulipan
Copy link
Contributor

@bkokoszx @plbossart Do we also need to create some new dapm structure for this? I think we do not have a suitable kind of widget in topology for this new feature.

@plbossart
Copy link
Member

@juimonen @ranj063 can you comment on the DAPM/topology question?
I would think there's no need for a new widget, the following definition should work

#define SND_SOC_TPLG_DAPM_EFFECT	18

@xiulipan
Copy link
Contributor

@plbossart @juimonen @ranj063 I will start to work with the SND_SOC_TPLG_DAPM_EFFECT
@bkokoszx If we would like to use the SND_SOC_TPLG_DAPM_EFFECT, we will not use a new comp struct. Please check the workflow of the KPB, MUX and DEMUX.

@bkokoszx
Copy link
Collaborator Author

@xiulipan
Ok, so will you use the following ipc structure?

struct sof_ipc_comp_process {
	struct sof_ipc_comp comp;
	struct sof_ipc_comp_config config;
	uint32_t size;	/**< size of bespoke data section in bytes */
	uint32_t type;	/**< sof_ipc_effect_type */

	/* reserved for future use */
	uint32_t reserved[7];

	unsigned char data[0];
} __attribute__((packed));

@xiulipan
Copy link
Contributor

@bkokoszx You can take the reference of kpb enable patch. https://github.com/thesofproject/sof/blob/master/src/audio/kpb.c

sof/src/audio/kpb.c

Lines 1356 to 1369 in 3d5d314

struct comp_driver comp_kpb = {
.type = SOF_COMP_KPB,
.ops = {
.new = kpb_new,
.free = kpb_free,
.cmd = kpb_cmd,
.trigger = kpb_trigger,
.copy = kpb_copy,
.prepare = kpb_prepare,
.reset = kpb_reset,
.cache = kpb_cache,
.params = NULL,
},
};

So the only specific variable for the smart_amp is uint32_t feedback_buf_id; ?

@bkokoszx
Copy link
Collaborator Author

bkokoszx commented Oct 21, 2019

@xiulipan
Thanks.

I think we can even ignore uint32_t feedback_buf_id. I could "find" that buffer without feedback_buf_id in e.g.smart_amp_prepare() by connected components types.

Today I will try to update smart amp template.

@bkokoszx
Copy link
Collaborator Author

@xiulipan
Smart Amp template using struct sof_ipc_comp_process (without uint32_t feedback_buf_id) is available here:
https://github.com/thesofproject/sof/tree/topic/smart-amp-comp-process

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does this index represent? The component ID of the buffer? the topology ID?
There are so many indices throughout topology, kernel and firmware, you need to be more explicit on what this is tied to.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @plbossart , I've just updated PR and commit messages.

I've talked with @xiulipan and we decided to use sof_ipc_comp_process struct
(like e.g. in KPB; it does not have feedback_buf_id variable) instead of sof_ipc_comp_smart_amp.

@xiulipan
Copy link
Contributor

tplg PR: #1983
linux PR: thesofproject/linux#1343

Test with https://github.com/thesofproject/sof/commits/topic/smart-amp-comp-process
tplg can load, but could only play noise and record is not working.
not sure if I used wrong buffer size for the pipeline.

    0      2         PIPE 2.16    451028710.572917         9.062500 src/audio/pipeline.c:463    pipeline_prepare()
    0      2         HOST 2.8     451028721.406250        10.833333     src/audio/host.c:695    host_prepare()
    0      2       VOLUME         451028743.802083        22.395834 udio/volume/volume.c:589    volume_prepare()
    0      1         COMP         451028748.281250         4.479167 rc/audio/component.c:120    comp_set_sink_buffer() error: sink buffer size is not sufficient
    0      1       VOLUME         451028753.593750         5.312500 udio/volume/volume.c:624    volume_prepare() error: comp_set_sink_buffer() failed
    0      1         PIPE         451028759.270833         5.677083 src/audio/pipeline.c:470    pipeline_prepare() error: ret = -22,dev->comp.id = 8
    0      1          IPC         451028765.572917         6.302083    src/ipc/handler.c:305    ipc: pipe 2 comp 8 prepare failed -22

@bkokoszx
Copy link
Collaborator Author

bkokoszx commented Oct 22, 2019

@xiulipan
We've just checked similar tplg (with volume in playback and capture pipeline - as you illustrated here: #1983 (comment)) with slim driver and it works. There is no special requirement for buffer sizes (size is directly related to the pcm format and number of periods). All buffers you have created have the same size? Could you send full log?

@xiulipan
Copy link
Contributor

@bkokoszx Please check the logs. I tried
arecord first and aplay later.
log.txt

@zrombel
Copy link

zrombel commented Nov 27, 2019

Due to merg of PR #2029 and CI bit depth conversion tests changes - rebase is needed.

@lgirdwood
Copy link
Member

@bkokoszx any update ?

@lbetlej
Copy link
Collaborator

lbetlej commented Feb 4, 2020

SOFCI TEST

@bkokoszx
Copy link
Collaborator Author

SOFCI TEST

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be the last new one, @plbossart @kv2019i do you have a cut off date for this due to kernel impact.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Component types are going away. Lets not add any new ones.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had the same remark on the kernel side, even if we kept these comp_type it should be identified as 3rd-party stuff

Copy link
Contributor

@keyonjie keyonjie Apr 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart as replied on the kernel side, we plan to add config item for the 3rd-party algorithm specific selection, to the component itself, we want to make it a generic one with dummy(simple enough) algorithm, so if someone contribute an better open source algorithm, we can create an item for it also (something like a N->1 mux selection in the config menu).

@plbossart what's your suggestion about that?

@plbossart
Copy link
Member

Assuming we use this, what is the ABI level? Still ABI 15?

@bkokoszx bkokoszx force-pushed the topology-smart-amp-comp branch from b0aa325 to 1200bf4 Compare April 14, 2020 08:33
@bkokoszx
Copy link
Collaborator Author

@plbossart
I think so. I've rebased this PR.
@lgirdwood
What do you think?

@lgirdwood
Copy link
Member

@plbossart
I think so. I've rebased this PR.
@lgirdwood
What do you think?

Yep, ABI is set at MINOR 15 now for FW but where ie the kernel PR ???.

@keyonjie
Copy link
Contributor

@plbossart
I think so. I've rebased this PR.
@lgirdwood
What do you think?

Yep, ABI is set at MINOR 15 now for FW but where ie the kernel PR ???.

thesofproject/linux#1971

@lgirdwood
Copy link
Member

@bkokoszx sorry, needs to be MINOR 16 now - please check if any changes needed.

Add SOF_COMP_SMART_AMP type for smart amp component.
Basic topology using smart amplifier component
could be as follows:

                +------------------------------------------+
    +------+    | +---+  +-------------+  +---+  +-------+ |
    | Host |----->|Buf|->|  Smart Amp  |->|Buf|->|SSP Dai|-----------+
    +------+    | +---+  +-------------+  +---+  +-------+ |         |
                +-----------------^------------------------+         |
                                  |                                  |
                                +---+                                |
                                |Buf|                                |
                                +---+                                |
                                  ^                                  |
                +-----------------|--------------------------+       |
    +------+    | +---+  +--------|------+  +---+  +-------+ |       |
    | Host |<-----|Buf|<-|     Demux     |<-|Buf|<-|SSP Dai|<--------+
    +------+    | +---+  +---------------+  +---+  +-------+ |
                +--------------------------------------------+

Basic topology contains Smart Amp component in playback pipeline and Demux
component in capture pipeline. There is a additional buffer (feedback)
between them in order to process "feedback".

Signed-off-by: Bartosz Kokoszko <bartoszx.kokoszko@linux.intel.com>
@bkokoszx bkokoszx force-pushed the topology-smart-amp-comp branch from 1200bf4 to 49c8b59 Compare April 17, 2020 08:03
@bkokoszx
Copy link
Collaborator Author

@lgirdwood
Changed to MINOR 16.

@lgirdwood
Copy link
Member

@kv2019i kernel part ok ? if good we can merge on Monday ?

@kv2019i
Copy link
Collaborator

kv2019i commented Apr 20, 2020

@lgirdwood wrote:

@kv2019i kernel part ok ? if good we can merge on Monday ?

It seems ok, we have @plbossart request-changes still on this PR, would be good to get a formal ack on this.

@bkokoszx bkokoszx changed the title [RFC] topology: add ipc for smart amplifier component topology: add ipc for smart amplifier component Apr 29, 2020
@lgirdwood
Copy link
Member

@bkokoszx @keyonjie ping, any update ?

@bkokoszx
Copy link
Collaborator Author

bkokoszx commented May 7, 2020

@lgirdwood
If the ABI is correct, then I think we are up to date.

Copy link
Contributor

@keyonjie keyonjie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lgirdwood @kv2019i looks good to me.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kv2019i we are good from this end now.

@kv2019i
Copy link
Collaborator

kv2019i commented May 12, 2020

@kv2019i we are good from this end now.

Ack @lgirdwood . Kernel PR is now merged.

@lgirdwood
Copy link
Member

SOFCI TEST

@lgirdwood
Copy link
Member

Looks like CI needs rerun sine it was down when last update was pushed.

@lgirdwood
Copy link
Member

@dbaluta @paulstelian97 @dianacretu what's the ETA for imx qemu fix, I'm still seeing the qemu boot failure for one of the imx platforms with this PR. This is unrelated since this wont impact boot.

@paulstelian97
Copy link
Collaborator

@dbaluta @paulstelian97 @dianacretu what's the ETA for imx qemu fix, I'm still seeing the qemu boot failure for one of the imx platforms with this PR. This is unrelated since this wont impact boot.

No ETA for the moment but we'll think about it. I think the issue is that our platform only reports boot complete via the IPC and the qemu check doesn't look at the IPC. So there are two ways to go here. Either let Diana add a generic IPC implementation (which will be useful for the other platforms as well) or I implement trace points (allocate a shared memory space for trace point and panic information) and have her only rely on the trace point itself. I assume the second one is probably simpler but I want an internal discussion on this as well.

@lgirdwood
Copy link
Member

@paulstelian97 thanks for the update, I can apply this now and Diana can resolve the qemu CI issues when she is ready.

@lgirdwood lgirdwood merged commit 8a4ec56 into thesofproject:master May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ABI ABI change involved DSM Dynamic Speaker Management

Projects

None yet

Development

Successfully merging this pull request may close these issues.