Re: [AD] [BUG?] X11 Windowed driver delay...

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2004-02-19 at 01:35, Thomas Fjellstrom wrote:

> I'm starting to suspect the different ALSA hardware drivers all behave 
> differently... And the only way to get around this is to not use alsa's plain 
> "write" interface... Something with shared mem, callbacks, or whatever will 
> probably work better with allegro.
> 
> I really don't know anymore.. It was a pain to grep through ALSAs 
> "documentation", and through various headers...
> 
> I've had as much fun playing with ALSAs api as I've had playing with TCL in 
> eggdrop bots... (not fun at all.)
> 

Heh, I can imagine that :P Since the alsa5 and alsa9 code was splitted,
I had no more excuse to not look at it - and I finally got it to work :)

I'm still wondering though if a simple threaded version wouldn't be a
better idea. Is anyone still needing the unix-signals version of
Allegro? Not even AllegGL works with that version, so I guess ALSA
doesn't have to either.

But anyway, the polled version seems to work now. I had to fiddle around
quite a bit to make it play together with Allegro's "interrupt" context.
E.g. "poll" can't wait infinitly - instead it must return from the
"interrupt". Otherwise everything else, e.g. keyboard input, is stopped.

I'm not really 100% sure - but I think another problem was due to the
fragments loop, like I initially suspected. It somehow was re-mixing the
complete buffer for every fragment or something :P I just threw it all
out and did like in that ALSA example, and works perfectly here. I also
think samples, bytes, and the sample frames/points stuff was mixed up at
some places. If not, it is now :P

Some additional minor things:

- I set some SW parameters, like in the ALSA examples.

- Why was the driver using SND_PCM_FORMAT_S16_NE? Allegro has unsigned
samples - so I changed it to unsigned. Probably I'm overlooking
something here though - maybe only signed is guaranteed to work on all
ALSA drivers, but not unsigned, and therefore we should do the
conversion to unsigned? I also see there's some endianess detection in
the ALSA 5 driver.. probably on big endian the ALSA 9 driver won't work
currently.

- I changed ALSA_DEFAULT_NUMFRAGS from 16 to 5 - simply because that's
what is used in the ALSA example I was looking at.

- The following code fragment:

   if (fragsize < 0) {
      bps >>= 9;
      if (bps < 16)
	 bps = 16;

      fragsize = 1;
      while ((fragsize << 1) < bps)
	 fragsize <<= 1;
   }
   else {
      fragsize = fragsize * (alsa_bits / 8) * (alsa_stereo ? 2 : 1);
   }

I wasn't exactly sure what it does. So i replaced it by the below, where
ALSA_DEFAULT_BUFFER_MS is 100 and is the default fragment/period length
in ms.

   if (fragsize < 0) {
      int size = alsa_rate * ALSA_DEFAULT_BUFFER_MS / 1000 / numfrags;
      fragsize = 1;
      while (fragsize < size)
	 fragsize <<= 1;
   }

- Inside the xrun_recovery function, I commented out the handling of
ESTRPIPE. I must admit, I have no idea what it does. But sleeping for a
second, or in fact entering a loop which seems to wait much more time
than a second - all *inside an Allegro-interrupt* - definitely is plain
wrong - even if only done for ESTRPIPE.

Patch is attached. Regarding Allegro 4.1.13 - if this gets included
despite the freeze, we should still leave it at low priority I think -
since OSS works just as good.

-- 
Elias Pschernig <elias@xxxxxxxxxx>

Attachment: alsa9.diff.gz
Description: GNU Zip compressed data