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

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

[Jan Kiszka]

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... ]

Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
 audio/alsaaudio.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: b/audio/alsaaudio.c
===================================================================
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -58,7 +58,7 @@ static struct {
     int period_size_out_overridden;
     int verbose;
 } conf = {
-#define DEFAULT_BUFFER_SIZE 1024
+#define DEFAULT_BUFFER_SIZE 16*1024
 #define DEFAULT_PERIOD_SIZE 256
 #ifdef HIGH_LATENCY
     .size_in_usec_in = 1,
@@ -72,8 +72,8 @@ static struct {
     .buffer_size_out = 400000,
     .period_size_out = 400000 / 4,
 #else
-    .buffer_size_in = DEFAULT_BUFFER_SIZE * 4,
-    .period_size_in = DEFAULT_PERIOD_SIZE * 4,
+    .buffer_size_in = DEFAULT_BUFFER_SIZE,
+    .period_size_in = DEFAULT_PERIOD_SIZE,
     .buffer_size_out = DEFAULT_BUFFER_SIZE,
     .period_size_out = DEFAULT_PERIOD_SIZE,
     .buffer_size_in_overridden = 0,

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

[malc]

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.

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.

>
> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
> ---
> audio/alsaaudio.c |    6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: b/audio/alsaaudio.c
> ===================================================================
> --- a/audio/alsaaudio.c
> +++ b/audio/alsaaudio.c
> @@ -58,7 +58,7 @@ static struct {
>     int period_size_out_overridden;
>     int verbose;
> } conf = {
> -#define DEFAULT_BUFFER_SIZE 1024
> +#define DEFAULT_BUFFER_SIZE 16*1024
> #define DEFAULT_PERIOD_SIZE 256
> #ifdef HIGH_LATENCY
>     .size_in_usec_in = 1,
> @@ -72,8 +72,8 @@ static struct {
>     .buffer_size_out = 400000,
>     .period_size_out = 400000 / 4,
> #else
> -    .buffer_size_in = DEFAULT_BUFFER_SIZE * 4,
> -    .period_size_in = DEFAULT_PERIOD_SIZE * 4,
> +    .buffer_size_in = DEFAULT_BUFFER_SIZE,
> +    .period_size_in = DEFAULT_PERIOD_SIZE,
>     .buffer_size_out = DEFAULT_BUFFER_SIZE,
>     .period_size_out = DEFAULT_PERIOD_SIZE,
>     .buffer_size_in_overridden = 0,
>

-- 
mailto:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

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.

alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.input1'
alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.input2'
alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize ADC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.input3'
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.speaker'
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.headphone'
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
alsa: Could not initialize DAC
alsa: Failed to set period size 256
alsa: Reason: Invalid argument
audio: Failed to create voice `wm8750.monomix'

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[malc]

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.
>
> alsa: Could not initialize ADC
> alsa: Failed to set period size 256
> alsa: Reason: Invalid argument

The code first asks for minimal period size than adjusts period_size to be
no less than the obtained value then calls set_period which fails, there's
little that can be done which ammounts to(never tested):

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 43cfa25..ca17bc0 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;
                  }
              }


Could you give it a whirl please?

[..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.

-- 
mailto:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]

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.
>>
>> alsa: Could not initialize ADC
>> alsa: Failed to set period size 256
>> alsa: Reason: Invalid argument
> 
> The code first asks for minimal period size than adjusts period_size to be
> no less than the obtained value then calls set_period which fails, there's
> little that can be done which ammounts to(never tested):
> 
> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> index 43cfa25..ca17bc0 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;
>                  }
>              }
> 
> 
> Could you give it a whirl please?

No difference - except that it now complains about the 16384 byte buffer
size.

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?

> 
> [..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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[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:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4593 bytes --]

malc wrote:
> 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;
>              }
>          }

Yeah, great, that was the key! Find below the version that works for me
(on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!

Index: qemu/audio/alsaaudio.c
===================================================================
--- qemu/audio/alsaaudio.c	(Revision 4332)
+++ qemu/audio/alsaaudio.c	(Arbeitskopie)
@@ -396,7 +396,7 @@ static int alsa_open (int in, struct als
         }
         else {
             int dir;
-            snd_pcm_uframes_t minval;
+            snd_pcm_uframes_t minval, val;
 
             if (period_size) {
                 minval = period_size;
@@ -428,15 +428,16 @@ static int alsa_open (int in, struct als
                     }
                 }
 
-                err = snd_pcm_hw_params_set_period_size (
+                val = period_size;
+                err = snd_pcm_hw_params_set_period_size_near (
                     handle,
                     hw_params,
-                    period_size,
+                    &val,
                     0
                     );
                 if (err < 0) {
                     alsa_logerr2 (err, typ, "Failed to set period size %d\n",
-                                  req->period_size);
+                                  period_size);
                     goto err;
                 }
             }
@@ -466,14 +467,15 @@ static int alsa_open (int in, struct als
                 }
             }
 
-            err = snd_pcm_hw_params_set_buffer_size (
+            val = buffer_size;
+            err = snd_pcm_hw_params_set_buffer_size_near (
                 handle,
                 hw_params,
-                buffer_size
+                &val
                 );
             if (err < 0) {
                 alsa_logerr2 (err, typ, "Failed to set buffer size %d\n",
-                              req->buffer_size);
+                              buffer_size);
                 goto err;
             }
         }


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5529 bytes --]

Jan Kiszka wrote:
> malc wrote:
>> 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;
>>              }
>>          }
> 
> Yeah, great, that was the key! Find below the version that works for me
> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!

Declaring the buffer size tweak obsolete was too quick. I still need
more under certain guest load, but now I'm already fine with
DEFAULT_BUFFER_SIZE=4096. Or all in one:

Index: qemu/audio/alsaaudio.c
===================================================================
--- qemu/audio/alsaaudio.c	(Revision 4332)
+++ qemu/audio/alsaaudio.c	(Arbeitskopie)
@@ -58,7 +58,7 @@ static struct {
     int period_size_out_overridden;
     int verbose;
 } conf = {
-#define DEFAULT_BUFFER_SIZE 1024
+#define DEFAULT_BUFFER_SIZE 4096
 #define DEFAULT_PERIOD_SIZE 256
 #ifdef HIGH_LATENCY
     .size_in_usec_in = 1,
@@ -72,8 +72,8 @@ static struct {
     .buffer_size_out = 400000,
     .period_size_out = 400000 / 4,
 #else
-    .buffer_size_in = DEFAULT_BUFFER_SIZE * 4,
-    .period_size_in = DEFAULT_PERIOD_SIZE * 4,
+    .buffer_size_in = DEFAULT_BUFFER_SIZE,
+    .period_size_in = DEFAULT_PERIOD_SIZE,
     .buffer_size_out = DEFAULT_BUFFER_SIZE,
     .period_size_out = DEFAULT_PERIOD_SIZE,
     .buffer_size_in_overridden = 0,
@@ -396,7 +396,7 @@ static int alsa_open (int in, struct als
         }
         else {
             int dir;
-            snd_pcm_uframes_t minval;
+            snd_pcm_uframes_t minval, val;
 
             if (period_size) {
                 minval = period_size;
@@ -428,15 +428,16 @@ static int alsa_open (int in, struct als
                     }
                 }
 
-                err = snd_pcm_hw_params_set_period_size (
+                val = period_size;
+                err = snd_pcm_hw_params_set_period_size_near (
                     handle,
                     hw_params,
-                    period_size,
+                    &val,
                     0
                     );
                 if (err < 0) {
                     alsa_logerr2 (err, typ, "Failed to set period size %d\n",
-                                  req->period_size);
+                                  period_size);
                     goto err;
                 }
             }
@@ -466,14 +467,15 @@ static int alsa_open (int in, struct als
                 }
             }
 
-            err = snd_pcm_hw_params_set_buffer_size (
+            val = buffer_size;
+            err = snd_pcm_hw_params_set_buffer_size_near (
                 handle,
                 hw_params,
-                buffer_size
+                &val
                 );
             if (err < 0) {
                 alsa_logerr2 (err, typ, "Failed to set buffer size %d\n",
-                              req->buffer_size);
+                              buffer_size);
                 goto err;
             }
         }


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[malc]

On Sun, 4 May 2008, Jan Kiszka wrote:

> Jan Kiszka wrote:
>> malc wrote:
>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>

[..snip..]

>>
>> Yeah, great, that was the key! Find below the version that works for me
>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>
> Declaring the buffer size tweak obsolete was too quick. I still need
> more under certain guest load, but now I'm already fine with
> DEFAULT_BUFFER_SIZE=4096. Or all in one:

I wonder if everyone will be happy with quadrupled latency, apart from
you and this other user on some (kvm was it) mailing list there are no
huge outcries of dissatisfaction, then again i'm not sure how many people
use ALSA+QEMU or QEMUs+AUDIO in general.

[..snip..]

-- 
mailto:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

malc wrote:
> On Sun, 4 May 2008, Jan Kiszka wrote:
> 
>> Jan Kiszka wrote:
>>> malc wrote:
>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>
> 
> [..snip..]
> 
>>>
>>> Yeah, great, that was the key! Find below the version that works for me
>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>>
>> Declaring the buffer size tweak obsolete was too quick. I still need
>> more under certain guest load, but now I'm already fine with
>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
> 
> I wonder if everyone will be happy with quadrupled latency, apart from

Hmm, I wonder about the scenario where this latency may actually hurt.
QEMU is not /that/ fast anyway. ;)

> you and this other user on some (kvm was it) mailing list there are no
> huge outcries of dissatisfaction, then again i'm not sure how many people
> use ALSA+QEMU or QEMUs+AUDIO in general.

I don't think many users are actually running QEMU (or KVM) against
ALSA. You have to
 - manually enable it during configure
 - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
   ran into this trap first.)
 - possibly have to fix up your configuration with FIXED_FREQ and
   BUFFER_SIZE (as reported by >1 kvm users) until

As OSS does not give us shared sound device access and, in the end, is a
deprecated API under Linux, my goal is to overcome remaining issues of
the ALSA support and then make /this/ the default one (under Linux).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[malc]

On Mon, 5 May 2008, Jan Kiszka wrote:

> malc wrote:
>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>
>>> Jan Kiszka wrote:
>>>> malc wrote:
>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>
>>
>> [..snip..]
>>
>>>>
>>>> Yeah, great, that was the key! Find below the version that works for me
>>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>>>
>>> Declaring the buffer size tweak obsolete was too quick. I still need
>>> more under certain guest load, but now I'm already fine with
>>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
>>
>> I wonder if everyone will be happy with quadrupled latency, apart from
>
> Hmm, I wonder about the scenario where this latency may actually hurt.
> QEMU is not /that/ fast anyway. ;)

You would be surprised.

>
>> you and this other user on some (kvm was it) mailing list there are no
>> huge outcries of dissatisfaction, then again i'm not sure how many people
>> use ALSA+QEMU or QEMUs+AUDIO in general.
>
> I don't think many users are actually running QEMU (or KVM) against
> ALSA. You have to
> - manually enable it during configure
> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>   ran into this trap first.)

I don't see how it's a trap. You can also enable esd or fmod drivers
in configure along with alsa, which one should be the default?

> - possibly have to fix up your configuration with FIXED_FREQ and
>   BUFFER_SIZE (as reported by >1 kvm users) until
>
> As OSS does not give us shared sound device access and, in the end, is a
> deprecated API under Linux, my goal is to overcome remaining issues of
> the ALSA support and then make /this/ the default one (under Linux).
>

Huh? Even OSS/lite that is/was shipping with default Linux gave me
"shared" sound, though i had a decent sound card with possibility to
open the same /dev/dsp 16 times (it actually had 16 sigmatel chips on
board). And the real OSS has vmix. And fwiw to have this wonderful
"shared" sound you have to configure "dmix" (or whatever its called)
too.

-- 
mailto:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

malc wrote:
> On Mon, 5 May 2008, Jan Kiszka wrote:
> 
>> malc wrote:
>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>> malc wrote:
>>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>>
>>>
>>> [..snip..]
>>>
>>>>>
>>>>> Yeah, great, that was the key! Find below the version that works
>>>>> for me
>>>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>>>>
>>>> Declaring the buffer size tweak obsolete was too quick. I still need
>>>> more under certain guest load, but now I'm already fine with
>>>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
>>>
>>> I wonder if everyone will be happy with quadrupled latency, apart from
>>
>> Hmm, I wonder about the scenario where this latency may actually hurt.
>> QEMU is not /that/ fast anyway. ;)
> 
> You would be surprised.

Tell me more! :->

> 
>>
>>> you and this other user on some (kvm was it) mailing list there are no
>>> huge outcries of dissatisfaction, then again i'm not sure how many
>>> people
>>> use ALSA+QEMU or QEMUs+AUDIO in general.
>>
>> I don't think many users are actually running QEMU (or KVM) against
>> ALSA. You have to
>> - manually enable it during configure
>> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>>   ran into this trap first.)
> 
> I don't see how it's a trap. You can also enable esd or fmod drivers
> in configure along with alsa, which one should be the default?

For sure, you need this mechanism with >1 audio backends being enabled
in parallel. It's just the question how one is supposed to find out
about this additional requirement:

$ grep -r QEMU_AUDIO_DRV qemu
qemu/audio/audio.c:        "  set QEMU_AUDIO_DRV=wav\n"
qemu/audio/audio.c:        "  export QEMU_AUDIO_DRV=wav\n"
qemu/audio/audio.c:        drvname = audio_get_conf_str ("QEMU_AUDIO_DRV", NULL, &def);

Am I missing some reference? Then sorry in advance.

> 
>> - possibly have to fix up your configuration with FIXED_FREQ and
>>   BUFFER_SIZE (as reported by >1 kvm users) until
>>
>> As OSS does not give us shared sound device access and, in the end, is a
>> deprecated API under Linux, my goal is to overcome remaining issues of
>> the ALSA support and then make /this/ the default one (under Linux).
>>
> 
> Huh? Even OSS/lite that is/was shipping with default Linux gave me
> "shared" sound, though i had a decent sound card with possibility to
> open the same /dev/dsp 16 times (it actually had 16 sigmatel chips on
> board). And the real OSS has vmix. And fwiw to have this wonderful
> "shared" sound you have to configure "dmix" (or whatever its called)
> too.

Well, probably configurable as well with compat-OSS (real OSS is dead on
Linux). The fact is that - not only for me - this sharing does not work
out-of-the-box with OSS, while it does with ALSA. Don't ask me why, I'm
not an expert on this, I'm rather looking at it from a "normal" user
perspective.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[malc]

On Tue, 6 May 2008, Jan Kiszka wrote:

> malc wrote:
>> On Mon, 5 May 2008, Jan Kiszka wrote:
>>
>>> malc wrote:
>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>
>>>>> Jan Kiszka wrote:
>>>>>> malc wrote:
>>>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>>>
>>>>
>>>> [..snip..]
>>>>
>>>>>>
>>>>>> Yeah, great, that was the key! Find below the version that works
>>>>>> for me
>>>>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please merge!
>>>>>
>>>>> Declaring the buffer size tweak obsolete was too quick. I still need
>>>>> more under certain guest load, but now I'm already fine with
>>>>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
>>>>
>>>> I wonder if everyone will be happy with quadrupled latency, apart from
>>>
>>> Hmm, I wonder about the scenario where this latency may actually hurt.
>>> QEMU is not /that/ fast anyway. ;)
>>
>> You would be surprised.
>
> Tell me more! :->

The only thing that i care about: DOS demos and to lesser extent old DOS
games.

>>
>>>
>>>> you and this other user on some (kvm was it) mailing list there are no
>>>> huge outcries of dissatisfaction, then again i'm not sure how many
>>>> people
>>>> use ALSA+QEMU or QEMUs+AUDIO in general.
>>>
>>> I don't think many users are actually running QEMU (or KVM) against
>>> ALSA. You have to
>>> - manually enable it during configure
>>> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>>>   ran into this trap first.)
>>
>> I don't see how it's a trap. You can also enable esd or fmod drivers
>> in configure along with alsa, which one should be the default?
>
> For sure, you need this mechanism with >1 audio backends being enabled
> in parallel. It's just the question how one is supposed to find out
> about this additional requirement:

Being enabled? Did you mean being built in? And what do you mean by
mechanism, mechanism to do what exactly?

> $ grep -r QEMU_AUDIO_DRV qemu
> qemu/audio/audio.c:        "  set QEMU_AUDIO_DRV=wav\n"
> qemu/audio/audio.c:        "  export QEMU_AUDIO_DRV=wav\n"
> qemu/audio/audio.c:        drvname = audio_get_conf_str ("QEMU_AUDIO_DRV", NULL, &def);
>
> Am I missing some reference? Then sorry in advance.

What is the question?

[..snip..]

>
> Well, probably configurable as well with compat-OSS (real OSS is dead on
> Linux). The fact is that - not only for me - this sharing does not work
> out-of-the-box with OSS, while it does with ALSA. Don't ask me why, I'm
> not an expert on this, I'm rather looking at it from a "normal" user
> perspective.

It doesn't with ALSA on this machine, and on the machine next to this
one, and on machine that lies on the floor. It boils down to how ALSA
was configured by distribution maintainers.

-- 
mailto:av1474@comtv.ru

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

malc wrote:
> On Tue, 6 May 2008, Jan Kiszka wrote:
> 
>> malc wrote:
>>> On Mon, 5 May 2008, Jan Kiszka wrote:
>>>
>>>> malc wrote:
>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>
>>>>>> Jan Kiszka wrote:
>>>>>>> malc wrote:
>>>>>>>> On Sun, 4 May 2008, Jan Kiszka wrote:
>>>>>>>>
>>>>>
>>>>> [..snip..]
>>>>>
>>>>>>>
>>>>>>> Yeah, great, that was the key! Find below the version that works
>>>>>>> for me
>>>>>>> (on 64 bit 8) ). It even obsoletes my buffer size patch. Please
>>>>>>> merge!
>>>>>>
>>>>>> Declaring the buffer size tweak obsolete was too quick. I still need
>>>>>> more under certain guest load, but now I'm already fine with
>>>>>> DEFAULT_BUFFER_SIZE=4096. Or all in one:
>>>>>
>>>>> I wonder if everyone will be happy with quadrupled latency, apart from
>>>>
>>>> Hmm, I wonder about the scenario where this latency may actually hurt.
>>>> QEMU is not /that/ fast anyway. ;)
>>>
>>> You would be surprised.
>>
>> Tell me more! :->
> 
> The only thing that i care about: DOS demos and to lesser extent old DOS
> games.

And those suffer audibly if you increase QEMU_ALSA_DAC_BUFFER_SIZE?

> 
>>>
>>>>
>>>>> you and this other user on some (kvm was it) mailing list there are no
>>>>> huge outcries of dissatisfaction, then again i'm not sure how many
>>>>> people
>>>>> use ALSA+QEMU or QEMUs+AUDIO in general.
>>>>
>>>> I don't think many users are actually running QEMU (or KVM) against
>>>> ALSA. You have to
>>>> - manually enable it during configure
>>>> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>>>>   ran into this trap first.)
>>>
>>> I don't see how it's a trap. You can also enable esd or fmod drivers
>>> in configure along with alsa, which one should be the default?
>>
>> For sure, you need this mechanism with >1 audio backends being enabled
>> in parallel. It's just the question how one is supposed to find out
>> about this additional requirement:
> 
> Being enabled? Did you mean being built in? And what do you mean by
> mechanism, mechanism to do what exactly?

Yes, I meant built-in.

> 
>> $ grep -r QEMU_AUDIO_DRV qemu
>> qemu/audio/audio.c:        "  set QEMU_AUDIO_DRV=wav\n"
>> qemu/audio/audio.c:        "  export QEMU_AUDIO_DRV=wav\n"
>> qemu/audio/audio.c:        drvname = audio_get_conf_str
>> ("QEMU_AUDIO_DRV", NULL, &def);
>>
>> Am I missing some reference? Then sorry in advance.
> 
> What is the question?

Such kind of documentation is not for wimps. You know where to find and
why to use it, but does the average user do?

> [..snip..]
> 
>>
>> Well, probably configurable as well with compat-OSS (real OSS is dead on
>> Linux). The fact is that - not only for me - this sharing does not work
>> out-of-the-box with OSS, while it does with ALSA. Don't ask me why, I'm
>> not an expert on this, I'm rather looking at it from a "normal" user
>> perspective.
> 
> It doesn't with ALSA on this machine, and on the machine next to this
> one, and on machine that lies on the floor. It boils down to how ALSA
> was configured by distribution maintainers.

Chances are generally higher that broken ALSA setups are reported and
fixed than broken OSS emulations.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

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

[malc]

On Thu, 8 May 2008, Jan Kiszka wrote:

> malc wrote:
>> On Tue, 6 May 2008, Jan Kiszka wrote:
>>

[..snip..]

> And those suffer audibly if you increase QEMU_ALSA_DAC_BUFFER_SIZE?

The latency becomes noticable the audio should be okay.

>>
>>>>
>>>>>
>>>>>> you and this other user on some (kvm was it) mailing list there are no
>>>>>> huge outcries of dissatisfaction, then again i'm not sure how many
>>>>>> people
>>>>>> use ALSA+QEMU or QEMUs+AUDIO in general.
>>>>>
>>>>> I don't think many users are actually running QEMU (or KVM) against
>>>>> ALSA. You have to
>>>>> - manually enable it during configure
>>>>> - pass QEMU_AUDIO_DRV=alsa (OSS remains default even if ALSA is on - I
>>>>>   ran into this trap first.)
>>>>
>>>> I don't see how it's a trap. You can also enable esd or fmod drivers
>>>> in configure along with alsa, which one should be the default?
>>>
>>> For sure, you need this mechanism with >1 audio backends being enabled
>>> in parallel. It's just the question how one is supposed to find out
>>> about this additional requirement:
>>
>> Being enabled? Did you mean being built in? And what do you mean by
>> mechanism, mechanism to do what exactly?
>
> Yes, I meant built-in.
>
>>
>>> $ grep -r QEMU_AUDIO_DRV qemu
>>> qemu/audio/audio.c:        "  set QEMU_AUDIO_DRV=wav\n"
>>> qemu/audio/audio.c:        "  export QEMU_AUDIO_DRV=wav\n"
>>> qemu/audio/audio.c:        drvname = audio_get_conf_str
>>> ("QEMU_AUDIO_DRV", NULL, &def);
>>>
>>> Am I missing some reference? Then sorry in advance.
>>
>> What is the question?
>
> Such kind of documentation is not for wimps. You know where to find and
> why to use it, but does the average user do?

Sorry, i still do not understand the actual question you are/were asking.

>> [..snip..]
>>
>>>
>>> Well, probably configurable as well with compat-OSS (real OSS is dead on
>>> Linux). The fact is that - not only for me - this sharing does not work
>>> out-of-the-box with OSS, while it does with ALSA. Don't ask me why, I'm
>>> not an expert on this, I'm rather looking at it from a "normal" user
>>> perspective.
>>
>> It doesn't with ALSA on this machine, and on the machine next to this
>> one, and on machine that lies on the floor. It boils down to how ALSA
>> was configured by distribution maintainers.
>
> Chances are generally higher that broken ALSA setups are reported and
> fixed than broken OSS emulations.

There's nothing broken about it. Enabling dmix, thus degarding quality
and speed, is not what some may elect to do.

-- 
mailto:av1474@comtv.ru