[xine-user] Xine alsa issue update2

[P.C. C. <pc...@al...>]

Hi Simon,

Thank you for your comment.  The via686a driver from 2.4.x does not look

like alsa.  Since I have more or less switched to alsa for KDE2.1, it
would
be nice to get xine going on alsa.  Actually I could use the oss
emulator of
the alsa driver but it seems to have more audio ouch's, but alsa was
able to
play it clean if I could stop it from ckoking.

I said the integer type for nFill is not big enough to handle the count,
I
was wrong.  The size of integer on my machine was actually 32 bit long.
Sorry for the wrong information, I was still thinking about 16 bit
integer
of the good old days.

After looking at the alsa code, I found the driver was suffering from a
underrun when xine choked.    I tried to flow control the writing of the

samples but I could not eliminate the coking just by that.

In snd_pcm_lib_fill of pcm_lib.c, the alsa driver can stop the transfer
and
sets the status to  SND_PCM_STATUS_UNDERRUN directly even when the
stop_mode is set to SND_PCM_STOP_ROLLOVER.

Xine does not have code to handle the status change.  There was some
code to
handle the underrun field in ao_put_samples of audio_alsa_out.c but it
was
commented out.

I copied some code to handle the underrun and status change.  Now xine
can
keep playing without choking.  However it underruns very frequently that
it
sounds very ugly when I play mp3.

When playing DVDs it also underuns, but at a rate I can live with.   For
mp3s,
perhaps I could afford adding a delay in the loop since we do not have
to
worry about serving video.

I think I can tune xine to play both for my machine but it will be
machine
dependent.

As I said before, with some other CPU hungry processes running, the
underrun
becomes less frequent and can reach a point that the audio runs clean!

Renicing the process carrying the xine control loop also helps to
minimize
the underrun.

The fundamental issue is that the control loop is running very fast
non-stop
trying to figure out who needs service.  It is using nonblocking mode to

send samples to the alsa.  Sometimes it is running so fast and querying
the
alsa driver so often that it may not leave enough time for the driver to
do
its works and chokes.

Multithreading may be easier answer to handle the situation.

Regards,
P.C. Chan