virtio-sound Google Summer of Code project?

virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

Hi Shreyansh, Gerd, and Laurent,
The last virtio-sound RFC was sent in February last year. It was a
spare time project. Understandably it's hard to complete the whole
thing on weekends, evenings, etc. So I wanted to suggest relaunching
the virtio-sound effort as a Google Summer of Code project.

Google Summer of Code is a 12-week full-time remote work internship.
The intern would be co-mentored by some (or all) of us. The project
goal would be to merge virtio-sound with support for both playback and
capture. Advanced features for multi-channel audio, etc can be stretch
goals.

I haven't looked in detail at the patches from February 2022, so I
don't know the exact state and whether there is enough work remaining
for a 12-week internship. What do you think?

Stefan

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Hi Shreyansh, Gerd, and Laurent,
> The last virtio-sound RFC was sent in February last year. It was a
> spare time project. Understandably it's hard to complete the whole
> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> the virtio-sound effort as a Google Summer of Code project.
>
> Google Summer of Code is a 12-week full-time remote work internship.
> The intern would be co-mentored by some (or all) of us. The project
> goal would be to merge virtio-sound with support for both playback and
> capture. Advanced features for multi-channel audio, etc can be stretch
> goals.
>
> I haven't looked in detail at the patches from February 2022, so I
> don't know the exact state and whether there is enough work remaining
> for a 12-week internship. What do you think?

Adding Anton.

I have updated the old wiki page for this project idea and added it to
the 2023 ideas list:
https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound

Please let me know if you wish to co-mentor this project!

Stefan

Re: virtio-sound Google Summer of Code project?

[Alex Bennée]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> Hi Shreyansh, Gerd, and Laurent,
>> The last virtio-sound RFC was sent in February last year. It was a
>> spare time project. Understandably it's hard to complete the whole
>> thing on weekends, evenings, etc. So I wanted to suggest relaunching
>> the virtio-sound effort as a Google Summer of Code project.
>>
>> Google Summer of Code is a 12-week full-time remote work internship.
>> The intern would be co-mentored by some (or all) of us. The project
>> goal would be to merge virtio-sound with support for both playback and
>> capture. Advanced features for multi-channel audio, etc can be stretch
>> goals.
>>
>> I haven't looked in detail at the patches from February 2022, so I
>> don't know the exact state and whether there is enough work remaining
>> for a 12-week internship. What do you think?
>
> Adding Anton.
>
> I have updated the old wiki page for this project idea and added it to
> the 2023 ideas list:
> https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
>
> Please let me know if you wish to co-mentor this project!

I'd be happy to help - although if someone was rust inclined I'd also be
happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >>
> >> Hi Shreyansh, Gerd, and Laurent,
> >> The last virtio-sound RFC was sent in February last year. It was a
> >> spare time project. Understandably it's hard to complete the whole
> >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> >> the virtio-sound effort as a Google Summer of Code project.
> >>
> >> Google Summer of Code is a 12-week full-time remote work internship.
> >> The intern would be co-mentored by some (or all) of us. The project
> >> goal would be to merge virtio-sound with support for both playback and
> >> capture. Advanced features for multi-channel audio, etc can be stretch
> >> goals.
> >>
> >> I haven't looked in detail at the patches from February 2022, so I
> >> don't know the exact state and whether there is enough work remaining
> >> for a 12-week internship. What do you think?
> >
> > Adding Anton.
> >
> > I have updated the old wiki page for this project idea and added it to
> > the 2023 ideas list:
> > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> >
> > Please let me know if you wish to co-mentor this project!
>
> I'd be happy to help - although if someone was rust inclined I'd also be
> happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.

Maybe Gerd can tell us about the QEMU audio subsystem features that
may be lost if developing a standalone vhost-user device.

Two things come to mind:
1. May not run on all host OSes that QEMU supports if it supports
fewer native audio APIs than QEMU.
2. May not support forwarding audio to remote desktop solutions that
stream audio over the network. I don't know if/how this works with
VNC/RDP/Spice, but a separate vhost-user process will need to do extra
work to send the audio over the remote desktop connection.

I have CCed Marc-André for information on streaming audio over remote desktop.

Stefan

Re: virtio-sound Google Summer of Code project?

[Alex Bennée]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Stefan Hajnoczi <stefanha@gmail.com> writes:
>>
>> > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> >>
>> >> Hi Shreyansh, Gerd, and Laurent,
>> >> The last virtio-sound RFC was sent in February last year. It was a
>> >> spare time project. Understandably it's hard to complete the whole
>> >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
>> >> the virtio-sound effort as a Google Summer of Code project.
>> >>
>> >> Google Summer of Code is a 12-week full-time remote work internship.
>> >> The intern would be co-mentored by some (or all) of us. The project
>> >> goal would be to merge virtio-sound with support for both playback and
>> >> capture. Advanced features for multi-channel audio, etc can be stretch
>> >> goals.
>> >>
>> >> I haven't looked in detail at the patches from February 2022, so I
>> >> don't know the exact state and whether there is enough work remaining
>> >> for a 12-week internship. What do you think?
>> >
>> > Adding Anton.
>> >
>> > I have updated the old wiki page for this project idea and added it to
>> > the 2023 ideas list:
>> > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
>> >
>> > Please let me know if you wish to co-mentor this project!
>>
>> I'd be happy to help - although if someone was rust inclined I'd also be
>> happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
>
> Maybe Gerd can tell us about the QEMU audio subsystem features that
> may be lost if developing a standalone vhost-user device.
>
> Two things come to mind:
> 1. May not run on all host OSes that QEMU supports if it supports
> fewer native audio APIs than QEMU.
> 2. May not support forwarding audio to remote desktop solutions that
> stream audio over the network. I don't know if/how this works with
> VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> work to send the audio over the remote desktop connection.

Hmm good point. Maybe a stretch goal?

>
> I have CCed Marc-André for information on streaming audio over remote desktop.
>
> Stefan


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Tue, 31 Jan 2023 at 13:43, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >>
> >> Stefan Hajnoczi <stefanha@gmail.com> writes:
> >>
> >> > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >> >>
> >> >> Hi Shreyansh, Gerd, and Laurent,
> >> >> The last virtio-sound RFC was sent in February last year. It was a
> >> >> spare time project. Understandably it's hard to complete the whole
> >> >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> >> >> the virtio-sound effort as a Google Summer of Code project.
> >> >>
> >> >> Google Summer of Code is a 12-week full-time remote work internship.
> >> >> The intern would be co-mentored by some (or all) of us. The project
> >> >> goal would be to merge virtio-sound with support for both playback and
> >> >> capture. Advanced features for multi-channel audio, etc can be stretch
> >> >> goals.
> >> >>
> >> >> I haven't looked in detail at the patches from February 2022, so I
> >> >> don't know the exact state and whether there is enough work remaining
> >> >> for a 12-week internship. What do you think?
> >> >
> >> > Adding Anton.
> >> >
> >> > I have updated the old wiki page for this project idea and added it to
> >> > the 2023 ideas list:
> >> > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> >> >
> >> > Please let me know if you wish to co-mentor this project!
> >>
> >> I'd be happy to help - although if someone was rust inclined I'd also be
> >> happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
> >
> > Maybe Gerd can tell us about the QEMU audio subsystem features that
> > may be lost if developing a standalone vhost-user device.
> >
> > Two things come to mind:
> > 1. May not run on all host OSes that QEMU supports if it supports
> > fewer native audio APIs than QEMU.
> > 2. May not support forwarding audio to remote desktop solutions that
> > stream audio over the network. I don't know if/how this works with
> > VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> > work to send the audio over the remote desktop connection.
>
> Hmm good point. Maybe a stretch goal?

Let's see what Gerd and Marc-André think. It would be nice to
implement the device in Rust...

Stefan

Re: virtio-sound Google Summer of Code project?

[Marc-André Lureau]

Hi

On Tue, Jan 31, 2023 at 10:20 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> >
> > Stefan Hajnoczi <stefanha@gmail.com> writes:
> >
> > > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >>
> > >> Hi Shreyansh, Gerd, and Laurent,
> > >> The last virtio-sound RFC was sent in February last year. It was a
> > >> spare time project. Understandably it's hard to complete the whole
> > >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> > >> the virtio-sound effort as a Google Summer of Code project.
> > >>
> > >> Google Summer of Code is a 12-week full-time remote work internship.
> > >> The intern would be co-mentored by some (or all) of us. The project
> > >> goal would be to merge virtio-sound with support for both playback and
> > >> capture. Advanced features for multi-channel audio, etc can be stretch
> > >> goals.
> > >>
> > >> I haven't looked in detail at the patches from February 2022, so I
> > >> don't know the exact state and whether there is enough work remaining
> > >> for a 12-week internship. What do you think?
> > >
> > > Adding Anton.
> > >
> > > I have updated the old wiki page for this project idea and added it to
> > > the 2023 ideas list:
> > > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> > >
> > > Please let me know if you wish to co-mentor this project!
> >
> > I'd be happy to help - although if someone was rust inclined I'd also be
> > happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
>
> Maybe Gerd can tell us about the QEMU audio subsystem features that
> may be lost if developing a standalone vhost-user device.
>
> Two things come to mind:
> 1. May not run on all host OSes that QEMU supports if it supports
> fewer native audio APIs than QEMU.

Using GStreamer in Rust is well supported, and should give all the
backends that you ever need (alternatively, there might be some Rust
audio crates that I am not aware of). In all cases, I would not
implement various backends the way QEMU audio/ has grown...

> 2. May not support forwarding audio to remote desktop solutions that
> stream audio over the network. I don't know if/how this works with
> VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> work to send the audio over the remote desktop connection.

Well, some of the goal with `-display dbus` is to move the remote
desktop handling outside of QEMU. I had in mind that the protocol will
have to evolve to handle multiprocess, so audio, display, input etc
interfaces can be provided by external processes. In fact, it should
be possible without protocol change for audio devices with the current
interface (https://gitlab.com/qemu-project/qemu/-/blob/master/ui/dbus-display1.xml#L483).

In short, I wish the project implements the device in Rust, with
`gstreamer` and `dbus` as optional features. (that should be
introspectable via --print-capabilities stuff)

-- 
Marc-André Lureau

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Tue, 31 Jan 2023 at 14:48, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Tue, Jan 31, 2023 at 10:20 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
> > >
> > >
> > > Stefan Hajnoczi <stefanha@gmail.com> writes:
> > >
> > > > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > >>
> > > >> Hi Shreyansh, Gerd, and Laurent,
> > > >> The last virtio-sound RFC was sent in February last year. It was a
> > > >> spare time project. Understandably it's hard to complete the whole
> > > >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> > > >> the virtio-sound effort as a Google Summer of Code project.
> > > >>
> > > >> Google Summer of Code is a 12-week full-time remote work internship.
> > > >> The intern would be co-mentored by some (or all) of us. The project
> > > >> goal would be to merge virtio-sound with support for both playback and
> > > >> capture. Advanced features for multi-channel audio, etc can be stretch
> > > >> goals.
> > > >>
> > > >> I haven't looked in detail at the patches from February 2022, so I
> > > >> don't know the exact state and whether there is enough work remaining
> > > >> for a 12-week internship. What do you think?
> > > >
> > > > Adding Anton.
> > > >
> > > > I have updated the old wiki page for this project idea and added it to
> > > > the 2023 ideas list:
> > > > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> > > >
> > > > Please let me know if you wish to co-mentor this project!
> > >
> > > I'd be happy to help - although if someone was rust inclined I'd also be
> > > happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
> >
> > Maybe Gerd can tell us about the QEMU audio subsystem features that
> > may be lost if developing a standalone vhost-user device.
> >
> > Two things come to mind:
> > 1. May not run on all host OSes that QEMU supports if it supports
> > fewer native audio APIs than QEMU.
>
> Using GStreamer in Rust is well supported, and should give all the
> backends that you ever need (alternatively, there might be some Rust
> audio crates that I am not aware of). In all cases, I would not
> implement various backends the way QEMU audio/ has grown...
>
> > 2. May not support forwarding audio to remote desktop solutions that
> > stream audio over the network. I don't know if/how this works with
> > VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> > work to send the audio over the remote desktop connection.
>
> Well, some of the goal with `-display dbus` is to move the remote
> desktop handling outside of QEMU. I had in mind that the protocol will
> have to evolve to handle multiprocess, so audio, display, input etc
> interfaces can be provided by external processes. In fact, it should
> be possible without protocol change for audio devices with the current
> interface (https://gitlab.com/qemu-project/qemu/-/blob/master/ui/dbus-display1.xml#L483).
>
> In short, I wish the project implements the device in Rust, with
> `gstreamer` and `dbus` as optional features. (that should be
> introspectable via --print-capabilities stuff)

Cool, then let's go with a Rust vhost-user device implementation!

Can you elaborate on how the "gstreamer" feature would be used by the
process launching the vhost-user back-end? Do you mean there should be
a standard command-line syntax for specifying the playback and capture
devices that maps directly to GStreamer (e.g. like gst-launch-1.0)?

Stefan

Re: virtio-sound Google Summer of Code project?

[Marc-André Lureau]

Hi

On Wed, Feb 1, 2023 at 12:29 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Tue, 31 Jan 2023 at 14:48, Marc-André Lureau
> <marcandre.lureau@gmail.com> wrote:
> >
> > Hi
> >
> > On Tue, Jan 31, 2023 at 10:20 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >
> > > On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
> > > >
> > > >
> > > > Stefan Hajnoczi <stefanha@gmail.com> writes:
> > > >
> > > > > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > > >>
> > > > >> Hi Shreyansh, Gerd, and Laurent,
> > > > >> The last virtio-sound RFC was sent in February last year. It was a
> > > > >> spare time project. Understandably it's hard to complete the whole
> > > > >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> > > > >> the virtio-sound effort as a Google Summer of Code project.
> > > > >>
> > > > >> Google Summer of Code is a 12-week full-time remote work internship.
> > > > >> The intern would be co-mentored by some (or all) of us. The project
> > > > >> goal would be to merge virtio-sound with support for both playback and
> > > > >> capture. Advanced features for multi-channel audio, etc can be stretch
> > > > >> goals.
> > > > >>
> > > > >> I haven't looked in detail at the patches from February 2022, so I
> > > > >> don't know the exact state and whether there is enough work remaining
> > > > >> for a 12-week internship. What do you think?
> > > > >
> > > > > Adding Anton.
> > > > >
> > > > > I have updated the old wiki page for this project idea and added it to
> > > > > the 2023 ideas list:
> > > > > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> > > > >
> > > > > Please let me know if you wish to co-mentor this project!
> > > >
> > > > I'd be happy to help - although if someone was rust inclined I'd also be
> > > > happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
> > >
> > > Maybe Gerd can tell us about the QEMU audio subsystem features that
> > > may be lost if developing a standalone vhost-user device.
> > >
> > > Two things come to mind:
> > > 1. May not run on all host OSes that QEMU supports if it supports
> > > fewer native audio APIs than QEMU.
> >
> > Using GStreamer in Rust is well supported, and should give all the
> > backends that you ever need (alternatively, there might be some Rust
> > audio crates that I am not aware of). In all cases, I would not
> > implement various backends the way QEMU audio/ has grown...
> >
> > > 2. May not support forwarding audio to remote desktop solutions that
> > > stream audio over the network. I don't know if/how this works with
> > > VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> > > work to send the audio over the remote desktop connection.
> >
> > Well, some of the goal with `-display dbus` is to move the remote
> > desktop handling outside of QEMU. I had in mind that the protocol will
> > have to evolve to handle multiprocess, so audio, display, input etc
> > interfaces can be provided by external processes. In fact, it should
> > be possible without protocol change for audio devices with the current
> > interface (https://gitlab.com/qemu-project/qemu/-/blob/master/ui/dbus-display1.xml#L483).
> >
> > In short, I wish the project implements the device in Rust, with
> > `gstreamer` and `dbus` as optional features. (that should be
> > introspectable via --print-capabilities stuff)
>
> Cool, then let's go with a Rust vhost-user device implementation!
>
> Can you elaborate on how the "gstreamer" feature would be used by the
> process launching the vhost-user back-end? Do you mean there should be
> a standard command-line syntax for specifying the playback and capture
> devices that maps directly to GStreamer (e.g. like gst-launch-1.0)?

Roughly what comes in mind is that the backend should always offer a
--audio-backend=... option, defaulting to something sensible, and
always have `none`, I guess.
- when the `gstreamer` feature & capability is available, can be set
to 'gstreamer'. Additionally, options like --gst-sink='pipeline'
--gst-src='pipeline' could be supported too, but it should do
something sensible here as well, by using autoaudiosink/autoaudiosrc
by default.
- when the `dbus` feature & capability is available, can be set to
'dbus' (or qemu-dbus?). It may require some extra option too, to
communicate back with qemu, such as `--dbus-addr=addr`, or
`--dbus-fd=N`.


-- 
Marc-André Lureau

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Tue, 31 Jan 2023 at 16:19, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Wed, Feb 1, 2023 at 12:29 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Tue, 31 Jan 2023 at 14:48, Marc-André Lureau
> > <marcandre.lureau@gmail.com> wrote:
> > >
> > > Hi
> > >
> > > On Tue, Jan 31, 2023 at 10:20 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > >
> > > > On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.bennee@linaro.org> wrote:
> > > > >
> > > > >
> > > > > Stefan Hajnoczi <stefanha@gmail.com> writes:
> > > > >
> > > > > > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > > > >>
> > > > > >> Hi Shreyansh, Gerd, and Laurent,
> > > > > >> The last virtio-sound RFC was sent in February last year. It was a
> > > > > >> spare time project. Understandably it's hard to complete the whole
> > > > > >> thing on weekends, evenings, etc. So I wanted to suggest relaunching
> > > > > >> the virtio-sound effort as a Google Summer of Code project.
> > > > > >>
> > > > > >> Google Summer of Code is a 12-week full-time remote work internship.
> > > > > >> The intern would be co-mentored by some (or all) of us. The project
> > > > > >> goal would be to merge virtio-sound with support for both playback and
> > > > > >> capture. Advanced features for multi-channel audio, etc can be stretch
> > > > > >> goals.
> > > > > >>
> > > > > >> I haven't looked in detail at the patches from February 2022, so I
> > > > > >> don't know the exact state and whether there is enough work remaining
> > > > > >> for a 12-week internship. What do you think?
> > > > > >
> > > > > > Adding Anton.
> > > > > >
> > > > > > I have updated the old wiki page for this project idea and added it to
> > > > > > the 2023 ideas list:
> > > > > > https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound
> > > > > >
> > > > > > Please let me know if you wish to co-mentor this project!
> > > > >
> > > > > I'd be happy to help - although if someone was rust inclined I'd also be
> > > > > happy to mentor a rust-vmm vhost-user implementation of VirtIO sound.
> > > >
> > > > Maybe Gerd can tell us about the QEMU audio subsystem features that
> > > > may be lost if developing a standalone vhost-user device.
> > > >
> > > > Two things come to mind:
> > > > 1. May not run on all host OSes that QEMU supports if it supports
> > > > fewer native audio APIs than QEMU.
> > >
> > > Using GStreamer in Rust is well supported, and should give all the
> > > backends that you ever need (alternatively, there might be some Rust
> > > audio crates that I am not aware of). In all cases, I would not
> > > implement various backends the way QEMU audio/ has grown...
> > >
> > > > 2. May not support forwarding audio to remote desktop solutions that
> > > > stream audio over the network. I don't know if/how this works with
> > > > VNC/RDP/Spice, but a separate vhost-user process will need to do extra
> > > > work to send the audio over the remote desktop connection.
> > >
> > > Well, some of the goal with `-display dbus` is to move the remote
> > > desktop handling outside of QEMU. I had in mind that the protocol will
> > > have to evolve to handle multiprocess, so audio, display, input etc
> > > interfaces can be provided by external processes. In fact, it should
> > > be possible without protocol change for audio devices with the current
> > > interface (https://gitlab.com/qemu-project/qemu/-/blob/master/ui/dbus-display1.xml#L483).
> > >
> > > In short, I wish the project implements the device in Rust, with
> > > `gstreamer` and `dbus` as optional features. (that should be
> > > introspectable via --print-capabilities stuff)
> >
> > Cool, then let's go with a Rust vhost-user device implementation!
> >
> > Can you elaborate on how the "gstreamer" feature would be used by the
> > process launching the vhost-user back-end? Do you mean there should be
> > a standard command-line syntax for specifying the playback and capture
> > devices that maps directly to GStreamer (e.g. like gst-launch-1.0)?
>
> Roughly what comes in mind is that the backend should always offer a
> --audio-backend=... option, defaulting to something sensible, and
> always have `none`, I guess.
> - when the `gstreamer` feature & capability is available, can be set
> to 'gstreamer'. Additionally, options like --gst-sink='pipeline'
> --gst-src='pipeline' could be supported too, but it should do
> something sensible here as well, by using autoaudiosink/autoaudiosrc
> by default.
> - when the `dbus` feature & capability is available, can be set to
> 'dbus' (or qemu-dbus?). It may require some extra option too, to
> communicate back with qemu, such as `--dbus-addr=addr`, or
> `--dbus-fd=N`.

I see. Thanks for explaining.

I have updated the project idea now. Feel free to make edits or add
yourselves as mentors:
https://wiki.qemu.org/Internships/ProjectIdeas/VirtioSound

Stefan

Re: virtio-sound Google Summer of Code project?

[Anton Yakovlev]

Hi guys,

If anything, I'm here. Not sure I'll have time to be a mentor, but if there
are any questions I can answer, you're welcome.


On 31.01.2023 16:35, Stefan Hajnoczi wrote:
> On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> Hi Shreyansh, Gerd, and Laurent,
>> The last virtio-sound RFC was sent in February last year. It was a
>> spare time project. Understandably it's hard to complete the whole
>> thing on weekends, evenings, etc. So I wanted to suggest relaunching
>> the virtio-sound effort as a Google Summer of Code project.
>>
>> Google Summer of Code is a 12-week full-time remote work internship.
>> The intern would be co-mentored by some (or all) of us. The project
>> goal would be to merge virtio-sound with support for both playback and
>> capture. Advanced features for multi-channel audio, etc can be stretch
>> goals.
>>
>> I haven't looked in detail at the patches from February 2022, so I
>> don't know the exact state and whether there is enough work remaining
>> for a 12-week internship. What do you think?
> 
> Adding Anton.
> 
> I have updated the old wiki page for this project idea and added it to
> the 2023 ideas list:
> https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.qemu.org%2fInternships%2fProjectIdeas%2fVirtioSound&umid=dfa27714-6bd5-4f51-afb5-d0561afc03c8&auth=53c7c7de28b92dfd96e93d9dd61a23e634d2fbec-45bc593563b7a9935517db85a53255e7b79f3550
> 
> Please let me know if you wish to co-mentor this project!
> 
> Stefan

-- 
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

On Mon, 6 Feb 2023 at 03:33, Anton Yakovlev
<anton.yakovlev@opensynergy.com> wrote:
> If anything, I'm here. Not sure I'll have time to be a mentor, but if there
> are any questions I can answer, you're welcome.

Thank you, Anton!

Stefan

Re: virtio-sound Google Summer of Code project?

[Stefan Hajnoczi]

Hi everyone,
I have removed the project idea from the GSoC 2023 ideas list because
Stefano Garzarella is picking up Shreyansh's patches.

Stefan