[Top][All Lists]

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

Re: Fwd: VirtioSound device emulation implementation

From: Shreyansh Chouhan
Subject: Re: Fwd: VirtioSound device emulation implementation
Date: Thu, 11 Feb 2021 10:29:17 +0530

On Thu, 28 Jan 2021 at 23:04, Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> wrote:
I think I will give it a quick look :P
This certainly wasn't quick I admit.
Thanks a lot!

Hey! I hope you people are doing fine. :)
So colleges reopened and I was a bit busy for the past 2 weeks. Although I did get to work on this
on weekends.

So about the audiodev setup, I checked the source code on how it is setup, and I found out I
did not really have to do a lot for that. QEMU already registers the audiodev passed on command
line and later makes it to an audiostate, and adds it to the list of audiostates. And when the device
option is parsed, all its properties are set via the visitors iirc. So all I had to do was make a new device
type, define a QEMUSoundCard property and register it, and this should be enough to set the audio state for the QEMUSoundCard in this
new device. Do correct me if I am wrong here. (audiostates in turn contain the audiodev)

I have some code written, but it is a bit incomplete and I would like to complete at least the initialization
part before sending in patches for review. I wanted to ask some questions (again :P) regarding a few things.

I read the source code for the `gus` sound device. (gus.c) And set up the audiosettings and SWVoiceOut
from there. Here is my first question, I feel as if SWVoiceOut should be available per stream. So the
`VirtIOSound` device would have a list of `SWVoiceOut`?

Secondly I saw in the `ac97.c` source, (which is a PCI sound device,) a lot of PCIDev related set up in
the realize function, but they were not present in the `virtio-net.c` source. Do I need them? (`ac97.c` set
up PCI_COMMAND, PCI_STATUS, PCI_BASE_ADDRESS and similar things in PCIDev. For now the pci
setup in `virtio-snd-pci.c` basically mimics `virtio-net-pci.c` which uses a `VirtIOPCIProxy` obj.)

Thirdly, the properties are registered at two different places, once in the `virtio-net.c` source and once
in the `virtio-net-pci.c` source. I understand the the ones in `virito-net.c`/`virtio-snd.c` they are the device
properties, as in the configurations we can set for the device and other, well, properties. But what
exactly are the properties defined in the `virtio-net-pci.c` source file? I have a vague idea of
what they are, but I can't exactly put my finger on it. It's almost as if `virtio-net` and `virito-net-pci`
are two different devices each with thier own properties, and the virtio-net-pci helps communication
between virtio-net and QEMU guest. It registers using the same `type_init` macro, and that macro
registers modules which can later be initialized by QEMU if I am not wrong. Since I didn't get a lot
of time I was not able to really dig into the PCI code, and taking a look at it might make things clearer,
but once I started writing this mail, I thought I could ask this too.

Since there can be more than on streams and more than one jacks, we need to have a list of configurations
for them, and since they should be index adressable, should I use an array for them? When I was reading the
source I did not come across a QEMU list structure with indexed adressing. If there is one please let me know.

Finally, I do understand what the pcm streams are, and I have been able to set them up with hardcoded
initial configs (modulo the hda part). But I do not understand what exactly are `jacks` and what should I do to set them up.
Which source file should I look at for this? I came across a few jack related structs, but didn't see
a device using them. (I did not search for it as vigorously, I only tried grepping in `hw/audio` and the
only results were from `intel-hda-defs`. They were comments on enums. Again since I was writing
this mail I thought I should ask it here too.)

Shreyansh Chouhan

reply via email to

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