From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9D93C433E0 for ; Thu, 11 Feb 2021 05:01:54 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 37DEE64E7C for ; Thu, 11 Feb 2021 05:01:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37DEE64E7C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36764 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lA46z-0001Wx-7B for qemu-devel@archiver.kernel.org; Thu, 11 Feb 2021 00:01:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lA44j-0000Ti-Ps for qemu-devel@nongnu.org; Wed, 10 Feb 2021 23:59:35 -0500 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]:40768) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lA44g-00055K-N3 for qemu-devel@nongnu.org; Wed, 10 Feb 2021 23:59:33 -0500 Received: by mail-pj1-x1035.google.com with SMTP id z9so2727325pjl.5 for ; Wed, 10 Feb 2021 20:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0DJEGujP//6t2G4coxk++ZQCpff4e2SG2Rvn/K9fLQs=; b=TA/3e+5WE9OExz5mTlt6vnd9qTUr+Eo5yIGcXyPwk8tNQIA8AjfuKJCzaT5aKVHHFU B3YxMql8S4STwAHLy+VBd5lxtufUzBXn8hoUvbw67G7bq7k/Kq50s91hGoqNdYGQ57dv ZlHqF78ayt5GVYPQuxJ5oSclNqAXexFTg7n2BOCr2LYlysWhrRilss0/auEqvA/NdkcR xFwnrv3pYZzqs8D1xNbuhunK6Hz3lf0MtV9C2GG6DKPM7kZw2Yf8iivo4D4ZdTtPYkT3 HuyD8KMmUcPKMrEMSWN6BPG7Ym0gy826VHLDDN+VI7rfTFisHB/0e8BegXaO6bo+6O8k 7GVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0DJEGujP//6t2G4coxk++ZQCpff4e2SG2Rvn/K9fLQs=; b=EiP0P9jNsmy15ohku2XGwxvrwFTVTHpeIXaBiOtwDaPWP2Ayq7Pmfiu984ZfvLEBJF TcOJdOWAoGA4BzvpJ3ilo/jnxWsJIl6rCE3PgPwlVdz8MzEzUFVTJ51T9X43XWPKppEM 5VKfwYj9jspmpuiXrjwpclemWnk6tFh/e06/AYMn8gZCCwMz9ihPErh1ULgMER0XmXU6 HKqTAebKfDwqI3cJ9dPtCH+Byx0IbpGB2shkwEAqRGcBmYPG/JjCRe5YmxfKk34TZf98 q6EMlLpwDZk8xkrCo8Q+H11Fkah6aTiU40FPueFjXLr3p6CD/5Cs7hamLrNciasg+mKy dR3g== X-Gm-Message-State: AOAM530UUqPMxMw+BuoUOn4c2Jrl99ZjqJm0e/fkrBOhA5nPF7Fp7l3s fNUEHp5My1P93ch/9uCq1R9PuyM7x+DiM2vOabc= X-Google-Smtp-Source: ABdhPJx/EZxz9VPwsN3EZov0Nbhy0q14jC2aBdm0QW8VlT4/6/b2gQmOF6rT+S+F6lWs/fmv3d7n2k6HRVu5oFJEbVw= X-Received: by 2002:a17:902:6b01:b029:da:d295:2582 with SMTP id o1-20020a1709026b01b02900dad2952582mr6236156plk.14.1613019568259; Wed, 10 Feb 2021 20:59:28 -0800 (PST) MIME-Version: 1.0 References: <87ft33l8an.fsf@linaro.org> <87v9blmf1x.fsf@linaro.org> <20210128112541.qjpve3qbjy46ofkk@sirius.home.kraxel.org> <20210128163001.jjptft2t5fbdlvyn@sirius.home.kraxel.org> In-Reply-To: From: Shreyansh Chouhan Date: Thu, 11 Feb 2021 10:29:17 +0530 Message-ID: Subject: Re: Fwd: VirtioSound device emulation implementation To: Gerd Hoffmann Content-Type: multipart/alternative; boundary="00000000000061c5b405bb08621b" Received-SPF: pass client-ip=2607:f8b0:4864:20::1035; envelope-from=chouhan.shreyansh2702@gmail.com; helo=mail-pj1-x1035.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?QWxleCBCZW5uw6ll?= , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000061c5b405bb08621b Content-Type: text/plain; charset="UTF-8" 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! > -- > Shreyansh > > 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.) Regards, Shreyansh Chouhan --00000000000061c5b405bb08621b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 28 Jan 2021 at 23:04, Shreyan= sh 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!
--
Shreyansh<= br>

Hey! I hope you peop= le are doing fine. :)
So colleges reopened and I was a bit busy f= or the past 2 weeks. Although I did get to work on this
on weeken= ds.

So about the audiodev setup, I checked the sou= rce code on how it is setup, and I found out I
did not really hav= e to do a lot for that. QEMU already registers the audiodev passed on comma= nd
line and later makes it to an audiostate, and adds it to the l= ist 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 ne= w device
type, define a QEMUSoundCard property and register it, a= nd this should be enough to set the audio state for the QEMUSoundCard in th= is
new device. Do correct me if I am wrong here. (audiostates in = turn contain the audiodev)

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

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

Secondly I saw in the `ac97.c` source, (which is a PCI soun= d 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 sim= ilar 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 diffe= rent places, once in the `virtio-net.c` source and once
in the `v= irtio-net-pci.c` source. I understand the the ones in `virito-net.c`/`virti= o-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 v= irtio-net-pci helps communication
between virtio-net and QEMU gue= st. 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 d= ig 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 to= o.

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

Finally, I do understand what the pcm streams are, a= nd 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` an= d what should I do to set them up.
Which source file should I loo= k 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 o= nly 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.)

Regards,
Shreyansh Chouhan
--00000000000061c5b405bb08621b--