[MPlayer-dev-eng] Alsa output issue with rme9632 (small buffers)

[Ed Wildgoose]

> setting different periods and periodsizes is still possible in current 
> ao_alsa/mplayer. see my mail to the alsa-devel-list. your changes 
> should be put there. what to do about the delay changes? i currently 
> don't now. this whole delay thing looks hackish to me. probably 
> another supopt should be added cause im afraid that this hw-setup wont 
> work with other (consumer) cards.


The "-abs" option that you refer to says "deprecated" in the 
instructions.  In any case it's rather a hack in it's own right, but 
certainly I could also add my override there as well.  However, as it 
stands none of those options set buffer size to be anything larger than 
1024, so they aren't any better than the defaults.  The default also 
appears to be "stuck on", and override the defaults set at the top of 
the module.

I would prefer to try and work out a heuristic which should work for 
everyone though.  In actual fact I don't see any negative implications 
of increasing the buffer sizes with the Alsa output layer - there 
appears to be no difference in responsiveness (as far as I can tell)?  
If so, then simply increasing it further will have no ill effects I think?

The current choice of values seems to be somewhat arbitrary anyway, but 
increasing the buffersize should have little negative effects I think.  
And the change to drop number of periods is not that essential, but 
would likely keep more than enough latency in the system for most people 
I think.  Lets change it back to 16 if you think there is a problem

To be honest, the stuff above just helps me out a little, it doesn't 
change the problem.  The problem is actually that line where we 
determine how long to sleep for.  Because the current code only keeps 
the buffer 60% full, people with two buffers will eventually time 
underrun because they will have one full buffer and the other only 5% 
full (ie <60% total).  Changing this line to keep it, say, 40% full, 
fixes it for me, and in fact right now I think I must be running at 2 x 
1024 without any underruns, software scaling, with bicubic 
interpolation.  I will chuck in a  background compile in a second to 
give it a really good test, but it's pretty impressive already! 

However, I would appeal to you to test bumping up the default buffer 
size to at least 2048 since this obviously doubles the audio latency for me.

Here is a repeat of the patch with number of buffers left at 16.  I 
would be interested to hear if anyone finds this makes things less 
responsive for them

Thanks

Ed Wildgoose


diff -r -u ./libao2/ao_alsa.c 
../../../mplayer-1.0_pre5-r2.orig/work/MPlayer-1.0pre5/libao2/ao_alsa.c
--- ./libao2/ao_alsa.c  2004-08-04 17:39:47.688171381 +0100
+++ 
../../../mplayer-1.0_pre5-r2.orig/work/MPlayer-1.0pre5/libao2/ao_alsa.c     
2004-07-14 16:46:33.000000000 +0100
@@ -54,11 +54,14 @@
 static snd_pcm_hw_params_t *alsa_hwparams;
 static snd_pcm_sw_params_t *alsa_swparams;

+/* possible 4096, original 8192
+ * was only needed for calculating chunksize? */
+static int alsa_fragsize = 4096;
 /* 16 sets buffersize to 16 * chunksize is as default 1024
  * which seems to be good avarge for most situations
  * so buffersize is 16384 frames by default */
-static int alsa_fragcount = 8;
-static snd_pcm_uframes_t chunk_size = 4096;//is alsa_fragsize / 4
+static int alsa_fragcount = 16;
+static snd_pcm_uframes_t chunk_size = 1024;//is alsa_fragsize / 4

 #define MIN_CHUNK_SIZE 1024

@@ -467,7 +470,7 @@
     }

     //sets buff/chunksize if its set manually
-    if (ao_data.buffersize > 0) {
+    if (ao_data.buffersize) {
       switch (ao_data.buffersize)
        {
        case 1:
diff -r -u ./mplayer.c 
../../../mplayer-1.0_pre5-r2.orig/work/MPlayer-1.0pre5/mplayer.c
--- ./mplayer.c 2004-08-04 14:22:59.000000000 +0100
+++ ../../../mplayer-1.0_pre5-r2.orig/work/MPlayer-1.0pre5/mplayer.c    
2004-08-04 13:56:55.000000000 +0100
@@ -2184,11 +2184,11 @@

        // delay = amount of audio buffered in soundcard/driver
        if(delay>0.25) delay=0.25; else
-       if(delay<0.05) delay=0.05;
-       if(time_frame>delay*0.25){
+       if(delay<0.10) delay=0.10;
+       if(time_frame>delay*0.6){
            // sleep time too big - may cause audio drops (buffer underrun)
            frame_time_remaining=1;
-           time_frame=delay*0.25;
+           time_frame=delay*0.5;
        }

       } else {