On Tue, 31 Jan 2023 at 14:48, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > > Hi > > On Tue, Jan 31, 2023 at 10:20 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > On Tue, 31 Jan 2023 at 12:43, Alex Bennée <alex.ben...@linaro.org> wrote: > > > > > > > > > Stefan Hajnoczi <stefa...@gmail.com> writes: > > > > > > > On Sun, 29 Jan 2023 at 17:10, Stefan Hajnoczi <stefa...@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
