alsaaudio: increase default buffer sizes

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 <[email protected]>

---
audio/alsaaudio.c | 6 +++---

1 file changed, 3 insertions(+), 3 deletions(-)

Index: b/audio/alsaaudio.c
===================================================================

audio/alsaaudio.c +3 -3

@@ -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,

Quoted 4 lines · 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.

Quoted 2 lines

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

Quoted 9 lines · malc

Quoted 6 lines · 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... ]

Quoted 4 lines

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

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.

Quoted 1 line

Quoted 5 lines

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.

Quoted 11 lines · Jan Kiszka

Quoted 10 lines · malc

Quoted 7 lines · 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... ]

Quoted 8 lines

Quoted 4 lines

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):

audio/alsaaudio.c +3 -3

index 43cfa25..ca17bc0 100644
@@ -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..]

Quoted 12 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 17 lines · malc

Quoted 15 lines · Jan Kiszka

Quoted 14 lines · malc

Quoted 7 lines · 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... ]

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.

Quoted 3 lines

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?

Quoted 15 lines

[..snip..]

Quoted 12 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 19 lines · Jan Kiszka

Quoted 18 lines · malc

Quoted 16 lines · Jan Kiszka

Quoted 15 lines · malc

Quoted 7 lines · 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... ]

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

Quoted 6 lines

Quoted 3 lines

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

audio/alsaaudio.c +3 -3

index 43cfa25..59c091d 100644
@@ -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;

                 }
             }

audio/alsaaudio.c +3 -3

@@ -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;
             }

         }

Quoted 67 lines · malc

Quoted 18 lines · Jan Kiszka

Quoted 17 lines · malc

Quoted 15 lines · Jan Kiszka

Quoted 14 lines · malc

Quoted 7 lines · 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... ]

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

Quoted 4 lines

Quoted 2 lines

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

audio/alsaaudio.c +3 -3

index 43cfa25..59c091d 100644
@@ -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;

                 }
             }

audio/alsaaudio.c +2 -2

@@ -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",

Quoted 5 lines

audio/alsaaudio.c +1 -1

-                              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!

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

Quoted 3 lines

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:

Quoted 4 lines · Jan Kiszka

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

[..snip..]

Quoted 1 line

Quoted 1 line

Quoted 6 lines

Quoted 2 lines

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.

Quoted 13 lines · malc

Quoted 4 lines · Jan Kiszka

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

[..snip..]

Quoted 4 lines

Quoted 3 lines

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!

Quoted 5 lines

Quoted 3 lines

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. ;)

Quoted 4 lines

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

Quoted 19 lines · Jan Kiszka

Quoted 18 lines · malc

Quoted 4 lines · Jan Kiszka

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

[..snip..]

Quoted 8 lines

Quoted 4 lines

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:

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 6 lines

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.

Quoted 5 lines

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?

Quoted 8 lines

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

Quoted 21 lines · malc

Quoted 19 lines · Jan Kiszka

Quoted 18 lines · malc

Quoted 4 lines · Jan Kiszka

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

[..snip..]

Quoted 8 lines

Quoted 4 lines

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:

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

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! :->

Quoted 13 lines

Quoted 12 lines

Quoted 6 lines

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

Quoted 2 lines

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.

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.

Quoted 28 lines · Jan Kiszka

Quoted 27 lines · malc

Quoted 24 lines · Jan Kiszka

Quoted 15 lines · malc

Quoted 4 lines · Jan Kiszka

Quoted 3 lines · Jan Kiszka

Quoted 2 lines · malc

On Sun, 4 May 2008, Jan Kiszka wrote:

[..snip..]

Quoted 6 lines

Quoted 5 lines

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!

Quoted 5 lines

Quoted 3 lines

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. ;)

Quoted 3 lines

Quoted 1 line

You would be surprised.

Tell me more! :->

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

Quoted 17 lines

Quoted 16 lines

Quoted 8 lines

Quoted 7 lines

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.

Quoted 5 lines

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?

Quoted 3 lines

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?

Quoted 8 lines

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

Quoted 6 lines

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.

Quoted 2 lines · malc

On Tue, 6 May 2008, Jan Kiszka wrote:

And those suffer audibly if you increase QEMU_ALSA_DAC_BUFFER_SIZE?

Quoted 17 lines

Quoted 17 lines

Quoted 16 lines

Quoted 8 lines

Quoted 7 lines

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.

Quoted 5 lines

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?

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 7 lines

$ 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);

Quoted 3 lines

Quoted 1 line

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?

Quoted 9 lines

[..snip..]

Quoted 6 lines

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.

Quoted 3 lines

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.