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) -- Marc-André Lureau
