Skip to content

Conversation

@ranj063
Copy link
Collaborator

@ranj063 ranj063 commented Mar 16, 2022

No description provided.

ranj063 added 2 commits March 16, 2022 13:34
remove init for ret.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Remove init for source. It is not needed anymore.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
@ranj063 ranj063 force-pushed the fix/codec_bytes_to_process branch 2 times, most recently from 9f57812 to 92e3a22 Compare March 16, 2022 22:17
@dbaluta
Copy link
Collaborator

dbaluta commented Mar 17, 2022

First there is a compilation error that needs to be fixed:

In file included from /home/daniel/work/sof_dir/sof/src/include/sof/audio/buffer.h:20,
                 from /home/daniel/work/sof_dir/sof/src/audio/codec_adapter/codec_adapter.c:16:
/home/daniel/work/sof_dir/sof/src/audio/codec_adapter/codec_adapter.c: In function 'codec_adapter_copy':
/home/daniel/work/sof_dir/sof/src/include/sof/coherent.h:274:10: error: 'src_buffer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  274 |   c->key = k_spin_lock(&c->lock);
/home/daniel/work/sof_dir/sof/src/audio/codec_adapter/codec_adapter.c:505:23: note: 'src_buffer' was declared here
  505 |   struct comp_buffer *src_buffer;
      |                       ^~~~~~~~~~
[ 80%] Building C object CMakeFiles/sof.dir/src/lib/notifier.c.o
[ 82%] Building C object CMakeFiles/sof.dir/src/lib/pm_runtime.c.o
[ 82%] Building C object CMakeFiles/sof.dir/src/lib/clk.c.o
[ 83%] Building C object CMakeFiles/sof.dir/src/lib/dma.c.o

@ranj063 ranj063 force-pushed the fix/codec_bytes_to_process branch from 8b5e036 to 8874273 Compare March 17, 2022 13:32
@ranj063 ranj063 force-pushed the fix/codec_bytes_to_process branch 2 times, most recently from 1d0af51 to aa185f3 Compare March 17, 2022 18:06
Copy link
Contributor

Choose a reason for hiding this comment

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

does this mean it is no longer up to the IPC messages to allocate the buffers?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@cujomalainey sorry not following the question. Which buffers are you alluding to? This list of buffers is a replacement for mod->local_buff which assumes there's only one sink for a module. So we expand it to a list to support multiple sinks

Copy link
Contributor

Choose a reason for hiding this comment

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

what does mean "support multiple sinks".?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@lenghonglin imagine a demux where you can have a single source split and copied to multiple sinks. Thats is what I mean by "support multiple sinks"

Copy link
Contributor

Choose a reason for hiding this comment

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

got it

@ranj063 ranj063 force-pushed the fix/codec_bytes_to_process branch 6 times, most recently from 74165b9 to a11a065 Compare March 18, 2022 01:47
ranj063 added 3 commits March 17, 2022 20:40
Add a sink_buffer_list to struct processing_module to support multiple
output buffers for modules. Allocate sink buffers for all sinks during
prepare and copy the produced samples from the output_buffers into the
respective sink buffers during copy.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Add a helper function to copy from local buffer to the sink buffer. This
will be used to copy from all output buffers.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Modify all codec implementations to copy the produced samples to the
output_buffer. Copy the produced samples from all output buffers in the
sink_buffer_list. Remove local_buff from struct processing_module as it
is no longer needed.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
@ranj063 ranj063 force-pushed the fix/codec_bytes_to_process branch from 51358e0 to e562ecc Compare March 18, 2022 03:41
@ranj063
Copy link
Collaborator Author

ranj063 commented Mar 18, 2022

@markbartonxperi can you please check if this PR works for you?

@markbartonxperi
Copy link
Contributor

@ranj063 Looks good. Thanks!

Copy link
Collaborator

@dbaluta dbaluta left a comment

Choose a reason for hiding this comment

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

Thanks @ranj063 this works fine for i.MX. Also, incremental patches compile fine.

@lgirdwood
Copy link
Member

CI looks good.

@ranj063 ranj063 requested a review from cujomalainey March 18, 2022 16:08

copy_period:
comp_get_copy_limits_with_lock(src_buffer, sink_buffer, &cl);
copy_bytes = cl.frames * cl.source_frame_bytes;
Copy link
Contributor

Choose a reason for hiding this comment

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

What if copy_bytes is zero?

Copy link
Collaborator Author

@ranj063 ranj063 Mar 20, 2022

Choose a reason for hiding this comment

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

I dont think you can get here is copy_bytes is 0. we get to this point only if audio_stream_get_avail_bytes(&src_buffer->stream) conditions above are met

Copy link
Contributor

Choose a reason for hiding this comment

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

for dai comp, if comsumer(codec) slow than producter(codec_adapter), the dai buffer will be fulled, so in this condition, copy_bytes should be 0.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@lenghonglin even if copy_bytes is 0, the operations below will return without doing anything in that case. But sure, I can add a check for this in a follow up PR

@dbaluta dbaluta merged commit 4f8a70d into thesofproject:main Mar 21, 2022
@hlleng
Copy link
Contributor

hlleng commented Mar 22, 2022

There is another thing that i wanna disscuss.
For example, the mp3 is mpeg2 layer 3 16k 16bit . so codec_adapter input size is 72 bytes, output size is 1152 bytes. and the comp buffer size is 4k.
when host send TRIGER_STOP. there is 4k buffer in sof is not to be comused

So what time for host to send TRIGER_STOP?

@dbaluta
Copy link
Collaborator

dbaluta commented Mar 22, 2022

So, you say that we don't play the entire mp3 file till the end right? I think the solution here is to implement DRAIN. Patches are welcomed if you can implement this.

I have this on my todo list but with low prio this quarter.

@hlleng
Copy link
Contributor

hlleng commented Mar 22, 2022

ok, i will add this thing in my todolist

@ranj063 ranj063 deleted the fix/codec_bytes_to_process branch March 22, 2022 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants