Re: Is anything being done re: the pcm timeout issue?

On 09-Aug-2004 Rusty Nejdl wrote:
> Conrad J. Sabatier said:
>>
>> My problems are occurring on an amd64 box (Athlon 64) with the
>> nVidia nForce3 chipset (snd_ich driver).
>> 
>> Sounds works fine for a while, then suddenly I get a pcm play
>> timeout, and game over.  Have to reboot to get sound to work again.
>> 
>> Others have reported similar problems, but I've seen no followups
>> indicating anything is being done about it.
>> 
> 
> I've been seeing a sound issue on 5.2.1-release and I wonder if it's
> related at all to what you are seeing.  I have :
> 
> hw.snd.maxautovchans: 4
> hw.snd.pcm0.vchans: 4
> 
> And I have seen that these will eventually stop working one by one
> until I have none left.  lsof and fstat don't show any programs using
> them, but nonetheless, programms like xmms and gaim can't use them
> anymore.
> 
> Do you have any more details on the pcm play timeout?  Are you using
> vchans?  What program are you using?

No, no vchans in use here.  My main audio app is madplay, which I run
from a little "jukebox" script I wrote to play my MP3s.

I've been unable to determine what's triggering the breakage myself. 
The script runs fine for a while, selecting random MP3 files and
running madplay to play them one by one.  Suddenly, madplay will output
the message "output: write failed" (or something like that) and my
system log will show "pcm0:play:0: play interrupt timeout, channel
dead".

After that, any further attempts to play a sound file of any sort result
in only a split-second of sound followed by the same messages as above. 
The only cure is a reboot.

I posted some truss output from madplay a while back, but it's probably
not very useful, since a timeout had already occurred in a previous
run, so the listing only showed what was happening once the device had
already become broken.

Catching it "in the act", so to speak, is tricky, as it may work fine
for an hour or two before the first breakage occurs.  This would
require a HUGE amount of truss or ktrace logging.

We had a discussion recently here about certain peculiarities in the
sound code, but never reached any useful conclusions, and none of our
sound experts ever joined in, either.

I would hate to see 5.3 released with this problem still unsolved, but
it's beginning to look like that may, in fact, be the case,
unfortunately.  I had hoped, too, that by this time we would have seen
the new MIDI code incorporated into the tree as well, but it seems that
sound (other than the abrupt yanking of the previous MIDI code and
the recent renaming of devices/drivers) is being sadly neglected lately.

Perhaps I'm wrong on that and there's a lot of behind-the-scenes work
going on.  We're just not hearing anything lately, though, as to the
state of sound on FreeBSD, and it's really beginning to concern me a
lot. 

I realize I'm running amd64, and that problems are to be expected still
at this point, but the total lack of activity on the sound front lately
is leaving me increasingly pessimistic about FreeBSD's potential for
ever becoming a viable audio/music production environment.

I hate to say it, but AGNULA, a highly customized version of Debian or
Redhat (comes in both flavors) aimed at providing a rich environment
for audio/music production, is looking more and more tempting all the
time.  I would hate to have to go that route, but I'm having serious
doubts that FreeBSD will ever be competitive with Linux/ALSA in the
sound arena, which is really a shame, as it is otherwise such a superb
system.

-- 
Conrad J. Sabatier <conrads_at_cox.net> -- "In Unix veritas"