qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: VirtioSound device emulation implementation


From: Gerd Hoffmann
Subject: Re: Fwd: VirtioSound device emulation implementation
Date: Thu, 28 Jan 2021 12:25:41 +0100

On Thu, Jan 28, 2021 at 09:58:23AM +0530, Shreyansh Chouhan wrote:
> Thanks a lot Alex!
> 
> > All QEMU devices have two parts, a frontend (which the guest sees) and a
> > backend (which is how the data gets to somewhere in the host). Some of
> > the command line options in QEMU elide the details for convenience (-nic
> > and -drive are examples). The -netdev device is all about configuring
> > the backend of the network part for a paired -device front end. There is
> > a similar setup for audio (-audiodev) although I'll defer to Gerd's
> > expertise on how the two interact.
> 
> This helped me understand a bit more about how the devices work. In the
> source
> code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think the
> pci device is what is visible to the guest.
> So `virtio-net-pci.c` should be the front end?

Well, virtio can have different transports, thats why the separation.
pci is the most common one, but there are also mmio (supported by x86
microvm and arm/aarch64 virt) and ccw (used on s390x).

virtio-net.c is the actual virtio device, virtio-net-pci.c has mostly
glue code to make the virtio device visible on the pci bus.

> For the realize function, I saw that the `virtio_net_device_realize`
> function initializes
> the `net_conf` for the device. So I am guessing that the
> `virtio_snd_device_realize` function
> should initialize the number of jacks and streams a device has, along with
> the configuration
> for all these jacks and streams?

Yes.  net_conf is common config (backend, mac address, maybe more) for
network devices.  For sound devices that would audiodev (link the device
to a backend which then handles alsa/pulse/jack/oss/sdl/whatever).

Configuration can be done either using device properties, or by having
different devices.  Using device properties is probably the easier way
to go.  An example for the latter are the qemu hda codecs.  We have
three different devices:

 (1) hda-output: playback-only, offering a virtual line-out.
 (2) hda-duplex: record/playback, offering line-in and line-out.
 (3) hda-micro:  record/playback, offering microphone and speaker.

The difference between (2) and (3) is just the jack labeling, otherwise
the behavior is 100% identical (and they share the emulation code of
course).  But some windows VoIP apps didn't like the line-in and
complained about a missing microphone, so we added that ...

> The thing is I do not understand `net` devices all that well so I get a bit
> confused with
> what is specific to a net device and what should I actually be worried
> about :)

The only thing really required is the audiodev property.  Everything
else can be hard-coded initially, and once the basics are working
refined (like adding properties for jack labels, ...).

> The device initalization step mentions that the jack and streams
> should be read and a query should be made for the config of all jacks
> and streams. What should be the default values of these
> configurations? I think the realize function is responsible for
> setting these up.

I'd start with offering a single 48000, 16bit, stereo, line-out pcm
playback channel.

HTH,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]