[Qemu-devel] Re: [PATCH] alsaaudio: increase default buffer sizes

[malc]

On Sun, 4 May 2008, Jan Kiszka wrote:

> malc wrote:
> > On Fri, 2 May 2008, Jan Kiszka wrote:
> >
> > > malc wrote:
> > > > On Fri, 2 May 2008, Jan Kiszka wrote:
> > > >
> > > > > Sound though the ALSA driver is skipping here unless I increase the
> > > > > buffer size. OSS seems to use 16K as well, and 1K was obviously to
> > > > > small
> > > > > for recording anyway.
> > > > >
> > > > > [ PS: Can someone explain to me why I also have to override the
> > > > > DAC/ADC_FIXED_FREQ to 48000 to make ALSA work? Suboptimal... ]
> > > >
> > > > How exactly it doesn't work if you don't override it? Do you get any
> > > > messages prefixed with "alsa:"? As for the defaults they were set to
> > > > 1024/256 because that's what was needed to make it sound on par with OSS
> > > > on the two machines i had at the time.

[..snip..]

> > Could you give it a whirl please?
>
> No difference - except that it now complains about the 16384 byte buffer
> size.

Okay more of the same...

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 43cfa25..59c091d 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -428,15 +428,15 @@ static int alsa_open (int in, struct alsa_params_req 
*req,
                     }
                 }

-                err = snd_pcm_hw_params_set_period_size (
+                err = snd_pcm_hw_params_set_period_size_near (
                     handle,
                     hw_params,
-                    period_size,
+                    &period_size,
                     0
                     );
                 if (err < 0) {
                     alsa_logerr2 (err, typ, "Failed to set period size 
%d\n",
-                                  req->period_size);
+                                  period_size);
                     goto err;
                 }
             }
@@ -466,14 +466,14 @@ static int alsa_open (int in, struct alsa_params_req 
*req,
                 }
             }

-            err = snd_pcm_hw_params_set_buffer_size (
+            err = snd_pcm_hw_params_set_buffer_size_near (
                 handle,
                 hw_params,
-                buffer_size
+                &buffer_size
                 );
             if (err < 0) {
                 alsa_logerr2 (err, typ, "Failed to set buffer size %d\n",
-                              req->buffer_size);
+                              buffer_size);
                 goto err;
             }
         }

> What indirect effect has the frequency difference (44k1 vs. 48k) on this
> size parameter, on its valid range, or whatever? Or is this service
> simply always failing because of a certain ALSA state?

I have no idea, sorry.

> > [..snip..]
> >
> > > BTW, I picked up those ALSA settings from user reports on kvm-devel,
> > > dating back to mid of last year. So I'm not alone, and it shouldn't be a
> > > wm8750-specific thing.
> > >
> > > > By the by: OSSs fragment size is specified in bytes, ALSAs on the other
> > > > hand in frames. So 16*1024 in the patch bellow means(considering
> > > > S16/stereo) 65536 bytes large buffer and 1024 bytes large period. For
> > > > OSS it's 16K bytes buffer and 4096 bytes period.
> > >
> > > Ah, OK. However, 4*1024 is not enough for the DAC here, and there were
> > > similar reports by kvm users.
> >
> > It's apparently plenty enough for ALSA when it emulates OSS and not when
> > it does things "native" way, oh boy.
>
> Maybe something else is broken, and this just happens to be a
> workaround. But I've no experience with the ALSA API, I'm only guessing.

The default values that are currently in are also taken from thin air, as
i mentioned earlier, they seemed to work on few machines i had around and
the latency was okay.

--
mailto:address@hidden