On Tue, Jan 22, 2019 at 6:22 PM Pierre-Louis Bossart
<pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote:
>
>
> On 1/22/19 1:35 AM, Daniel Baluta wrote:
> >> +static int byt_send_msg(struct snd_sof_dev *sdev, struct snd_sof_ipc_msg *msg)
> >> +{
> >> + u64 cmd = msg->header;
> >> +
> >> + /* send the message */
> >> + sof_mailbox_write(sdev, sdev->host_box.offset, msg->msg_data,
> >> + msg->msg_size);
> > I was wondering if the mailbox shared memory wouldn't be better
> > implemented as a queue.
> > Do you support playing multiple streams in parallel?
> >
> > We have this use case where we need to to memory to memory
> > decoding/encoding with lots
> > of streams in parallel.
>
> Sorry Daniel, I didn't get your point.
>
> we do support multiple streams in parallel and there's been quite a few
> issues fixed in the IPC mechanisms due to concurrency. The IPC mechanism
> is serialized however since there are only few resources available,
> typically only a couple of doorbell registers and a small memory window.
> For multiple streams the PCM data is exchanged over DMA typically - the
> streams don't go over the IPC channel but the information related to a
> stream is passed using a tag or ID.
>
> Can you clarify what you had in mind?
Sometimes is hard feven for me to clarify that :)
The question was raised mostly because our audio framework
uses queues here instead just of a mailbox.
We might actually need to have an implementation ready to test
if this serialization has an impact on performance.
I will get back to you when this question will make more sense
in my mind.
thanks,
daniel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
