public inbox for virtio-dev@lists.linux.dev
 help / color / mirror / Atom feed
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Radu Ocica <rocica@blackberry.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"anton.yakovlev@opensynergy.com" <anton.yakovlev@opensynergy.com>
Subject: Re: [virtio-dev] virtio-snd comments/questions
Date: Mon, 13 Nov 2023 12:16:36 +0100	[thread overview]
Message-ID: <ZVIFlIcOjW5+jgaH@fedora> (raw)
In-Reply-To: <37eaf0dc2bdb4a7b936618b48dd00ac2@blackberry.com>

Hello, 

On Thu, Nov 09, 2023 at 04:46:45PM +0000, Radu Ocica wrote:
> 
> > Could you elaborate on this? Which audio backend would not support
> > PAUSE? I am not very familiar with audio engines.
> 
> For instance in linux, alsa-lib has a flag that specifies pause support by a PCM stream:
> #define SNDRV_PCM_INFO_PAUSE                       (1UL<<19)  /* pause ioctl is supported */
> The snd_pcm_pause API can only be used successfully if the PCM stream has this bit set in its PCM info.
> A similar concept exists in QNX sound.
> 

Oh, I see. I was unaware of this flag. Not supporting PAUSE in the host
sound card may not be a problem. In our case, the pw backend in the host
stops playing when a guest sends STOP immediately. As soon as START is
sent again, pw begins consuming from the tx queue. Tx buffers are only
signaled as complete after START is reissued. In the meantime, the msgs
are in the available ring of the tx queue.

> However, if the host stream does not support pause the only option
> left is to perform a drop operation on the host stream and in this
> case all pending messages in the tx/rx queue need to be returned to
> the guest as completed, because at the next start possibly all
> messages will be needed to prime the host stream (in the case of
> playback).

If STOP is sent and there is still msgs in the TX queue, can't the
device just stop playing until START is issued again? Why does the
device require to drop the msgs in this case?

Thanks, Matias.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2023-11-13 11:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 15:32 [virtio-dev] virtio-snd comments/questions Radu Ocica
2023-10-24 10:18 ` Matias Ezequiel Vara Larsen
2023-11-03 19:05   ` Radu Ocica
2023-11-06 15:09     ` Matias Ezequiel Vara Larsen
2023-11-09 16:46       ` Radu Ocica
2023-11-10  7:57         ` Manos Pitsidianakis
2023-11-13 11:16         ` Matias Ezequiel Vara Larsen [this message]
2023-11-22 18:59           ` Radu Ocica
2023-11-27 11:20             ` Matias Ezequiel Vara Larsen
2023-10-24 13:30 ` Matias Ezequiel Vara Larsen
2023-11-03 18:17   ` Radu Ocica
2023-11-06 15:18     ` Matias Ezequiel Vara Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZVIFlIcOjW5+jgaH@fedora \
    --to=mvaralar@redhat.com \
    --cc=anton.yakovlev@opensynergy.com \
    --cc=rocica@blackberry.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox