[mythtv] read audio: File descriptor in bad state / Audio buffer overflow / Prebuffering pause

[Joe Hansche]

My mythtv setup has been working fairly well in the past.  0.15 was
working very well for me at the time I had it, but a sound problem
forced me to upgrade to 0.16, and other intermittent issues have been
popping up since.  Those problems still exist in my current version,
which is the CVS version 0.16.20041224-1, compiled from a fresh CVS
download on Jan 19, 05.

This is what happens...  mythbackend will start recording a program, and
it's doing fine.  Watching the recording, the video and audio are both
good.  But something (I don't know what, but I'm hoping someone can help
me pinpoint it) triggers a problem, and the backend is no longer able to
read audio from the stream.  I get the messages:

2005-01-20 20:13:28.411 NVR: Only read 1024 bytes of 4096 bytes from
'/dev/dsp
read audio: Success
2005-01-20 20:13:28.415 NVR: Only read -1 bytes of 4096 bytes from
'/dev/dsp
read audio: File descriptor in bad state
2005-01-20 20:13:28.416 NVR: Only read -1 bytes of 4096 bytes from
'/dev/dsp
read audio: File descriptor in bad state

repeated about 300 times per second (the average timestamp delta in the
log is anywhere from 0.000 to 0.010 seconds).  The first message appears
to be the final bit of data it receives from the audio buffer, and after
that, it always returns "-1".  At that point, the backend begins using
100% CPU, and will continue doing so until the backend is restarted, or
recording stops.  In the recording, audio becomes "stuck" so to speak,
as if it's continuously repeating the last 300-500ms that it was able to
read, and the video slows down to about 1/2 to 3/4 the original speed it
should be.

I even tried exiting X, and letting it sit at a console terminal while
recording, but it still happens, which leads me to believe it's not a
load issue (ie: it isn't a problem with the backend being choked of
resources due to something else hogging CPU or memory).

It doesn't seem to be dependent upon the channel, it happens equally as
often on any channel that it's recording, and also happens while
watching LiveTV sometimes.  That said, it is also not always
reproducible.  In fact, after making a few changes (disabled XvMC,
disabled opengl, switched from ALSA to OSS, and set both the backend and
frontend to SUID root) it actually got a lot better, and several
programs have been able to record without encountering this problem at
all, but it does still exist.  One program recorded this evening at 5pm,
and had no problems, but another program recorded at 7pm and I had to
restart the backend about 5 times in 30 minutes before I decided to
cancel the recording.

When watching a recording that has been affected by this in the
frontend, when it hits the point that the problem begins, it starts
spitting these messages to the console:

2005-01-20 22:02:57.981 prebuffering pause
2005-01-20 22:05:17.092 Audio buffer overflow, audio data lost!
2005-01-20 22:05:17.283 Audio buffer overflow, audio data lost!
2005-01-20 22:05:17.881 Audio buffer overflow, audio data lost!
2005-01-20 22:05:18.551 Audio buffer overflow, audio data lost!

The prebuffering pause message came about 2 minutes sooner, but the
playback was still okay after that, until the buffer overflow messages
begin.  From what I gather from the lists, these errors are somewhat
common, but I have rarely seen a solution to any of these reports, and
those that I have found, do not work in my case.

What can I do to help pinpoint whats causing this, and fix whatever it
is?  Hardware and version information is:

CPU: 2.53GHz P4
Mem: 512MB
Kernel: 2.6.9-gentoo-r6 (gentoo development sources)
ALSA: 1.0.6 (I know 1.0.8 is released, but I don't know how to patch the
kernel to use the latest version ... does anyone else?)
MythTV: 0.16 (cvs 20041224-1)
Tuner: Hauppauge WinCast/TV (old, using bt848 chip, bttv module)
Video Card: nVidia GeForce4 Ti 4400 (nvidia binary driver 1.0.6629)
X: X.org 6.8.0-r4, configured with Xinerama for TV out
Sound Card: Turtle Beach Santa Cruz (Cirrus Logic CS 4614/22/24, ALSA
driver = cs46xx)

Not sure what else is needed, but I'll provide any details you think may
be necessary .. just let me know and I'll get it.

Thanks,
Joe
-- 
madCoder
<madCoder at GameSurge.net>
GameSurge, Inc.
http://www.gamesurge.net/
[ SupportCOM | WebCom | GSDev | Routing | AUPEG ]