buffer: Create audio stream buffer

[ktrzcinx]

When new component will need to process audio data in two steps,
then temporary circular buffer will be needed. Also extra information
about data stream may be needed to choose right algorithm or assert data
compatibility.

Currently only 'comp_buffer' has such a possibility but it is component
defined in topology - with much wider capabilities - and shouldn't be
created inside component just to hold temporary data stream.

Signed-off-by: Karol Trzcinski [email protected]

[lgirdwood]

Why can we not reuse the existing buffer logic ? We should be able to instantiate it directly without IPC, although we may need some new API calls to help with this. I just don't want to see duplication here.

[ktrzcinx]

@lgirdwood I see that in currently we have tendency to duplications, see hb struct in sof/audio/kpb.h and as I far as I know there are similar issue currently under development. So I see need to split comp_buffer to part responsible directly for holding audio samples in circular buffer, base argument for data processing functions and universal brick for nesting when it is such a need.
As you can see I change almost each processing function in code and nowhere were used more fields than are present in this new structure - as usual there are need to only have circular buffer implementation with channel numbers and frame format.

[lgirdwood]

ok, it looks like duplication because patch 2 duplicates existing APIs and patch 3 removes the old API. You need to merge the parts of patch 2 into 3 to show that there is no duplication, this makes it easier to follow.

[lgirdwood]

@ktrzcinx one more question, will there be further updates to kpb to deduplicate code and fully use this update ?

[ktrzcinx]

@lgirdwood do You want to just fully merge patch #2 i #3 ?

[ktrzcinx]

Rebase required because of conflicts

[lgirdwood]

@zrombel could you comment on the scan. Thanks.

[zrombel]

Xtensa licese server issue. Rerunning build and scan. I've mode some changes to suppress those kind of issues.

[lgirdwood]

@xiulipan checkpatch is fine, but showing an error ?

[xiulipan]

@lgirdwood If you scroll down, you will find some warning:

Commit 0b45888e873f ("buffer: Create audio stream buffer")
----------------------------------------------------------
CHECK: Alignment should match open parenthesis
#2669: FILE: src/audio/src/src.c:778:
+		comp_update_buffer_consume(source,
+			consumed * audio_stream_frame_bytes(&source->stream));

CHECK: Alignment should match open parenthesis
#2675: FILE: src/audio/src/src.c:782:
+		comp_update_buffer_produce(sink,
+			produced * audio_stream_frame_bytes(&sink->stream));

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2959: FILE: src/include/sof/audio/audio_stream.h:43:
+#define audio_stream_read_frag(buffer, idx, size) \
+	audio_stream_get_frag(buffer, buffer->r_ptr, idx, size)

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2962: FILE: src/include/sof/audio/audio_stream.h:46:
+#define audio_stream_read_frag_s16(buffer, idx) \
+	audio_stream_get_frag(buffer, buffer->r_ptr, idx, sizeof(int16_t))

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2965: FILE: src/include/sof/audio/audio_stream.h:49:
+#define audio_stream_read_frag_s32(buffer, idx) \
+	audio_stream_get_frag(buffer, buffer->r_ptr, idx, sizeof(int32_t))

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2968: FILE: src/include/sof/audio/audio_stream.h:52:
+#define audio_stream_write_frag(buffer, idx, size) \
+	audio_stream_get_frag(buffer, buffer->w_ptr, idx, size)

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2971: FILE: src/include/sof/audio/audio_stream.h:55:
+#define audio_stream_write_frag_s16(buffer, idx) \
+	audio_stream_get_frag(buffer, buffer->w_ptr, idx, sizeof(int16_t))

CHECK: Macro argument reuse 'buffer' - possible side-effects?
#2974: FILE: src/include/sof/audio/audio_stream.h:58:
+#define audio_stream_write_frag_s32(buffer, idx) \
+	audio_stream_get_frag(buffer, buffer->w_ptr, idx, sizeof(int32_t))

CHECK: Alignment should match open parenthesis
#2978: FILE: src/include/sof/audio/audio_stream.h:62:
+static inline void *audio_stream_get_frag(const struct audio_stream *buffer,
+				const void *ptr, uint32_t idx, uint32_t size)

WARNING: Use safe version of memcpy - memcpy_s whenever possible
#4112: FILE: test/cmocka/src/audio/buffer/buffer_wrap.c:36:
+	memcpy(buf->stream.w_ptr, &bytes, 10);

WARNING: Use safe version of memcpy - memcpy_s whenever possible
#4125: FILE: test/cmocka/src/audio/buffer/buffer_wrap.c:45:
+	memcpy(buf->stream.w_ptr, &more_bytes, 5);

WARNING: Use safe version of memcpy - memcpy_s whenever possible
#4163: FILE: test/cmocka/src/audio/buffer/buffer_write.c:37:
+	memcpy(buf->stream.w_ptr, &bytes, 10);

WARNING: Use safe version of memcpy - memcpy_s whenever possible
#4201: FILE: test/cmocka/src/audio/buffer/buffer_write.c:72:
+	memcpy(buf->stream.w_ptr, &bytes, 10);

total: 0 errors, 4 warnings, 9 checks, 4349 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

[ktrzcinx]

@xiulipan @lgirdwood checkpack results is located on github inside iframe with size restrictions:
<p><iframe src="checkpatch.txt" frameborder="0" height="550" width="95%"></iframe></p>

It's quite misleading for me too, maybe it's time to use full available size instead?

[lgirdwood]

@xiulipan that was not visible yesterday when I checked (and I did double check as I found it odd), it was all good ? Could there be a sync issue ?

[lgirdwood]

@ktrzcinx can you send a followup PR with the memcpy fixes as per check patch.

[ktrzcinx]

@lgirdwood I didn't introduce memcpy functions in this place, it was before, but yes, I can fix it

[paulstelian97]

Memcpy functions seem to all be in unit tests? And the actual issue was old but only now discovered due to touching said code?

[ktrzcinx]

@paulstelian97 Right

[xiulipan]

@kakulesza @lrgirdwo @plbossart I think it would be some html issue. I wil try to and some fix to make the iframe scroll-able if the checkpatch result is very long.