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
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
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
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
> > 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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
>
> 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:
>>
>>
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
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
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
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
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
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
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
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
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
36 matches
Mail list logo
