In automotive, Android guests are currently used for deploying infotainment systems. To support Android as a guest, the Virtual Machine Monitor (VMM) requires a set of virtual hardware like sound, video and networking. In this context, VirtIO has spreaded as a standard interface for virtual devices. Having VirtIO for hardware allows Android to be deployed in different VMMs that support VirtIO like Crosvm or QEMU. This talk presents the current efforts to implement virtio-sound for infotainment systems in automotive. The implementation of virtio-sound can be split into two: the device or backend and the driver or the frontend. Generally speaking, the driver runs in the guest OS and it is not different from other sound drivers. The sound driver exposes an API to the user-application in guest and then communicates to the device to serve those requests like playing a sound or recording audio. The device usually runs in the host and processes the requests that come from the driver. There are different ways to implement the device, e.g., as a built-in device in QEMU, using vhost or vhost-user. In this talk, we talk about our decision to implement virtio-sound as an vhost-user device. In this case, the device runs in the host machine as a separate process independent of the QEMU process. This deployment has benefits like reducing the attack surface of QEMU and also enables more granularity in setting up rights for the device process. Our implementation is able to handle different audio backends by relying on a generic interface. Currently, we support the pipewire and Alsa as audio backends. During this presentation, we propose to share our journey in building the virtio-sound device, including improving its specification, fixing bugs in the virtio-sound driver, and building it as a rust-vmm project. We also plan to outline a roadmap for the future like adding support for other audio backends like Gstreamer.