On Mon, 7 Feb 2022 at 09:36, Shreyansh Chouhan
wrote:
>
> On Thu, 20 Jan 2022 at 16:09, Laurent Vivier wrote:
> >
> >
> > Hi,
> >
> > I'm trying to test your RFC series but I have a core dump (using alsa-utils
> > speaker-test), do you
> > have an updated branch I could pull?
>
> Yes, I will sen
On Thu, 20 Jan 2022 at 16:09, Laurent Vivier wrote:
>
> Le 29/12/2021 à 06:52, Shreyansh Chouhan a écrit :
> > Hi,
> >
> > I am sorry for the absence of activity on this. A couple of people very
> > close to me died, and I also
> > got busy
> > with the linux kernel mentorship program for a while
Le 29/12/2021 à 06:52, Shreyansh Chouhan a écrit :
Hi,
I am sorry for the absence of activity on this. A couple of people very close to me died, and I also
got busy
with the linux kernel mentorship program for a while. It was a weird year. But
I am back on this now.
I have the basic function
Hi,
I am sorry for the absence of activity on this. A couple of people very
close to me died, and I also got busy
with the linux kernel mentorship program for a while. It was a weird year.
But I am back on this now.
I have the basic functionality of the sound card working. I tested it on an
ubunt
> > AUD_write returns the number of bytes actually accepted.
> >
> > In case the audio backend consumed the complete buffer you can go ahead
> > as described. Otherwise stop here and resume (try AUD_write() the
> > remaining data) when the callback is called again.
> >
> The callback that is suppo
On Mon, 19 Apr 2021 at 18:00, Shreyansh Chouhan <
chouhan.shreyansh2...@gmail.com> wrote:
>
> On Fri, 16 Apr 2021 at 17:02, Gerd Hoffmann wrote:
>
>> Hi,
>>
>> > I learned that the callback passed in AUD_open_out, (lets call it the
>> write
>> > audio callback,) is supposed to mix and write th
On Fri, 16 Apr 2021 at 17:02, Gerd Hoffmann wrote:
> Hi,
>
> > I learned that the callback passed in AUD_open_out, (lets call it the
> write
> > audio callback,) is supposed to mix and write the
> > buffers to HWVoiceOut. I have written that, the basic algorithm being:
> >
> > 1. Pop element f
Hi,
> Starting off with the get config function for pcm streams. Initially I
> thought I was supposed to store those configs in the VirtIOSound
> struct but then I realized these configurations should be queried from
> the backend and then be presented to the driver/guest.
No. The device can c
Hey everyone!
I wrote code for PCM streams, which I'd like to discuss here. But since it
isn't
really complete yet, I thought I'd ask if I can copy paste the functions
that I want to ask
about and clear things that way.
For now I will just write my queries here and try to explain them as best
as I
Hi,
> 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.
Correct.
> So the `VirtIOSound` device would have a list of `SWVoiceOut`?
In the si
On Thu, 28 Jan 2021 at 23:04, Shreyansh Chouhan <
chouhan.shreyansh2...@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 th
On Thu, 28 Jan 2021 at 22:00, Gerd Hoffmann wrote:
> On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote:
> > (Gerd, I wasn't able to get gmail to quote your email, so I have just
> copy
> > pasted the relavant parts.)
> >
> > > Yes. net_conf is common config (backend, mac address,
On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote:
> (Gerd, I wasn't able to get gmail to quote your email, so I have just copy
> pasted the relavant parts.)
>
> > Yes. net_conf is common config (backend, mac address, maybe more) for
> > network devices. For sound devices that wo
(Gerd, I wasn't able to get gmail to quote your email, so I have just copy
pasted the relavant parts.)
> 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/ja
On Thu, 28 Jan 2021 at 16:54, Alex Bennée wrote:
>
> Shreyansh Chouhan writes:
>
> > 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 Q
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 f
Shreyansh Chouhan writes:
> 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 ex
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 ab
Shreyansh Chouhan writes:
> Just a follow up.
> Still working on device initialization. I am trying to understand the
> relation between virtio-net and net device in qemu
> in hopes of recreating something similar with the audio device.
All QEMU devices have two parts, a frontend (which the gu
Just a follow up.
Still working on device initialization. I am trying to understand the
relation between virtio-net and net device in qemu
in hopes of recreating something similar with the audio device. Once I have
the device initialization part
ready I will send in a couple of patches for review.
I wasn't really able to clearly understand how I will use QEMU VIrtqueues
exactly.
So, I decided that I will start implementing the part that I already
understand.
I think once I have something implemented I'll have a better chance at
understanding this.
I am currently writing the boilerplate code
I will make it an in-QEMU pci device. After it is done and the device is
working, I can
write a vhost-user daemon and move the device out of QEMU should it be
needed.
This way I'd already have the virtio-pci device tested out by the time I
get to the vhost-user
daemon. Also I'll be a lot more famil
>
> If you want to see an example of a branch new vhost-user daemon being
>> built up from scratch see my recent virtio-rpmb series. The first few
>> patches of in-QEMU code will be the same boilerplate either way I think:
>>
>> https://patchew.org/QEMU/20200925125147.26943-1-alex.ben...@linaro.o
On Thu, 14 Jan 2021 at 23:17, Alex Bennée wrote:
>
> Shreyansh Chouhan writes:
>
> > Just an update:
> >
> > I've studied the virtio specification along with the source code and I
> now
> > understand what the device implementation is
> > going to look like. Also I understand the source code a l
Shreyansh Chouhan writes:
> Just an update:
>
> I've studied the virtio specification along with the source code and I now
> understand what the device implementation is
> going to look like. Also I understand the source code a lot better. I am
> now reading about the qemu vhost-user protocol.
Just an update:
I've studied the virtio specification along with the source code and I now
understand what the device implementation is
going to look like. Also I understand the source code a lot better. I am
now reading about the qemu vhost-user protocol.
Although I haven't read about the vhost-
Shreyansh Chouhan writes:
> -- Forwarded message -
> From: Shreyansh Chouhan
> Date: Mon, 11 Jan 2021 at 11:59
> Subject: Re: VirtioSound device emulation implementation
> To: Gerd Hoffmann
>
>
>
>
> On Sun, 10 Jan 2021 at 13:55, Shreyansh
-- Forwarded message -
From: Shreyansh Chouhan
Date: Mon, 11 Jan 2021 at 11:59
Subject: Re: VirtioSound device emulation implementation
To: Gerd Hoffmann
On Sun, 10 Jan 2021 at 13:55, Shreyansh Chouhan <
chouhan.shreyansh2...@gmail.com> wrote:
> Hi,
>
> I ha
Hi,
I have been reading about the virtio and vhost specifications, however I
have a few doubts. I tried looking for them but I still
do not understand them clearly enough. From what I understand, there are
two protocols:
The virtio protocol: The one that specifies how we can have common
emulation
Hi,
> >> Are you planning to make it an in-QEMU device or maybe a external
> >> vhost-user daemon?
> >
> > The project page states that we need to use the QEMU audio subsystem
> > for playing and capturing audio samples.
>
> Is this one of the QEMU internship projects?
one of last years gsoc p
On Thu, 7 Jan 2021 at 22:49, Alex Bennée wrote:
>
> Shreyansh Chouhan writes:
>
> > On Wed, 6 Jan 2021 at 17:12, Alex Bennée wrote:
> >
> >>
> >> Shreyansh Chouhan writes:
> >>
> >> > Hey everyone!
> >> >
> >> > I want to work on implementing the emulation for the VritioSound
> device.
> >> I
Shreyansh Chouhan writes:
> On Wed, 6 Jan 2021 at 17:12, Alex Bennée wrote:
>
>>
>> Shreyansh Chouhan writes:
>>
>> > Hey everyone!
>> >
>> > I want to work on implementing the emulation for the VritioSound device.
>> I
>> > contacted the mentor for the project, (Greg), who said it's fine and
Hi,
> > Are you planning to make it an in-QEMU device or maybe a external
> > vhost-user daemon?
>
> The project page states that we need to use the QEMU audio subsystem
> for playing and capturing audio samples. I am not entirely sure if
> this implies that the device should be an in-QEMU devi
On Wed, 6 Jan 2021 at 17:12, Alex Bennée wrote:
>
> Shreyansh Chouhan writes:
>
> > Hey everyone!
> >
> > I want to work on implementing the emulation for the VritioSound device.
> I
> > contacted the mentor for the project, (Greg), who said it's fine and
> that I
> > should declare it on the ma
Shreyansh Chouhan writes:
> Hey everyone!
>
> I want to work on implementing the emulation for the VritioSound device. I
> contacted the mentor for the project, (Greg), who said it's fine and that I
> should declare it on the mailing list in order to find out if someone else
> is already workin
Hey everyone!
I want to work on implementing the emulation for the VritioSound device. I
contacted the mentor for the project, (Greg), who said it's fine and that I
should declare it on the mailing list in order to find out if someone else
is already working on this project. That is what this mail
36 matches
Mail list logo
