| Message ID | 20190911145818.18962-3-stefanha@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | audio: -audiodev documentation tweaks | expand |
On 2019-09-11 16:58, Stefan Hajnoczi wrote: > The "latency" parameter wasn't covered by the documentation. > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Zoltán Kővágó <DirtY.iCE.hu@gmail.com> > --- > How is this parameter related to buffer-length? Pulseaudio being a client-server architecture is a bit different than the other backends, plus it also has to mix multiple streams. buffer-length corresponds to the buffer inside qemu, while latency corresponds to pulseaudio. For playback, the latency should be "maximum latency that the application can deal with", if a different client request a lower latency, our latency will decrease too. It's up to the server to figure out an optimal buffer size on the server side of the things. For recording it's the size of the buffer we will read at a time from pulseaudio. > --- > qemu-options.hx | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/qemu-options.hx b/qemu-options.hx > index a4f9f74f52..82154cecf8 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -470,6 +470,7 @@ DEF("audiodev", HAS_ARG, QEMU_OPTION_audiodev, > "-audiodev pa,id=id[,prop[=value][,...]]\n" > " server= PulseAudio server address\n" > " in|out.name= source/sink device name\n" > + " in|out.latency= desired latency in microseconds\n" > #endif > #ifdef CONFIG_AUDIO_SDL > "-audiodev sdl,id=id[,prop[=value][,...]]\n" > @@ -630,6 +631,9 @@ Sets the PulseAudio @var{server} to connect to. > @item in|out.name=@var{sink} > Use the specified source/sink for recording/playback. > > +@item in|out.latency=@var{usecs} > +Desired latency in microseconds. > + > @end table > > @item -audiodev sdl,id=@var{id}[,@var{prop}[=@var{value}][,...]] >
On Tue, Sep 17, 2019 at 09:47:11PM +0200, Zoltán Kővágó wrote: > On 2019-09-11 16:58, Stefan Hajnoczi wrote: > > The "latency" parameter wasn't covered by the documentation. > > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > Reviewed-by: Zoltán Kővágó <DirtY.iCE.hu@gmail.com> > > --- > > How is this parameter related to buffer-length? > > Pulseaudio being a client-server architecture is a bit different than the > other backends, plus it also has to mix multiple streams. buffer-length > corresponds to the buffer inside qemu, while latency corresponds to > pulseaudio. For playback, the latency should be "maximum latency that the > application can deal with", if a different client request a lower latency, > our latency will decrease too. It's up to the server to figure out an > optimal buffer size on the server side of the things. > For recording it's the size of the buffer we will read at a time from > pulseaudio. Thanks for explaining. I will expand the help text in v2. Stefan
diff --git a/qemu-options.hx b/qemu-options.hx index a4f9f74f52..82154cecf8 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -470,6 +470,7 @@ DEF("audiodev", HAS_ARG, QEMU_OPTION_audiodev, "-audiodev pa,id=id[,prop[=value][,...]]\n" " server= PulseAudio server address\n" " in|out.name= source/sink device name\n" + " in|out.latency= desired latency in microseconds\n" #endif #ifdef CONFIG_AUDIO_SDL "-audiodev sdl,id=id[,prop[=value][,...]]\n" @@ -630,6 +631,9 @@ Sets the PulseAudio @var{server} to connect to. @item in|out.name=@var{sink} Use the specified source/sink for recording/playback. +@item in|out.latency=@var{usecs} +Desired latency in microseconds. + @end table @item -audiodev sdl,id=@var{id}[,@var{prop}[=@var{value}][,...]]
The "latency" parameter wasn't covered by the documentation. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> --- How is this parameter related to buffer-length? --- qemu-options.hx | 4 ++++ 1 file changed, 4 insertions(+)