[mythtv] "ran out of free AUDIO buffers :-(" Fix

[Xepo]

I'm using:
Mandrake 9.0
Athlon XP 1700+
Video: NVidia GeForce2 MX
Audio: On-Board VIA 686

This is with version 0.7.

I went through some trouble to get mythtv set up yesterday.

I was using OSS with the via82cxxx drivers, and anytime I executed
mythtv, my computer would hit the reset button -- immediately drop to a
reboot. I googled for it, and found it was probably related to sound.  I
had been wanting to install ALSA instead of OSS for a while, so I
decided to do it then.  Switching to ALSA fixed that problem.

After I had switched to ALSA, and modprobed the correct drivers(without
rebooting), the audio was skipping.  I had checked that the line-in was
muted, so that wasn't the problem.  My CPU's not at 100%, so that's not
the problem. I've still not figured this one out yet.

However, after I rebooted, any time I executed mythtv, I got repeated
"ran out of free AUDIO buffers :-(", and a very slow executing mythtv.

So I googled for it, didn't find much that helped, set off to fix it on
my own.  

After these changes to the sources, I no longer get this message, and it
runs just like it did before I rebooted.

In libs/libNuppelVideo/NuppelVideoRecorder.cpp:

Comment out lines 325-329
Comment out lines 1126-1131
Add in after line 1131: blocksize = 4096;
Change line 1224 from: usleep(1000);
to: usleep(100);


The main reason I don't just put a patch for it in here is because I'm
mostly unfamilar with this code, and I would like someone to check it
over before anyone else uses it.

The reason for commenting out those lines is on page 95 of the OSS
developers guide.  It says "Normally programs don't need to care about
the buffering parameters of audio devices.  However, most of the
features presented in this document have been designed to work with full
fragments.  For this reason, your program *may* work better if it reads
and writes data one buffer fragment at a time (please not that this is
not normally required).

Evidently this feature isn't too well tested, because leaving these
lines in there cause the "ran out of free AUDIO buffers" message.

The reason for changing the usleep:  If the write thread is started
before the buffering or encoding thread, then the write thread will
automatically wait one second for either of them.  I'm thinking that the
buffering or encoding threads run out of buffers before the writing
thread is done waiting one second.  Then it swaps around.  The encoding
or buffering threads are waiting a while, while the writing thread runs
out of buffers.

100ms was just an arbitrary number, I was going through the code and
trying to find the cause, saw that, thought "Why would something that's
supposed to be real-time be waiting a full second at any point?" and
tried out 100ms.  So, if you would like me to experiment more with this,
I will.  

If checking the buffering size actually helps performance that much, it
might be best to have the flag to change these things, and suggest it to
anyone who gets that message.  

Not changing either of these two things will bring back the error.

If this were fixed in the CVS version, then sorry for reposting.  But it
seems like very few people were having the problem, so I assume that it
isn't fixed.

Hope this helps.

Isaiah