On Tue, 2008-10-21 at 11:34 -0500, Rex Dieter wrote: > Dennis J. wrote: > > > It's obvious that the specific interaction between pulseaudio and alsa is > > the problem in these cases but if neither of the stakeholders feel > > particular responsible for addressing the issue then I don't see how this > > will ever get resolved. > > Personally, I've not seen any dismissing of responsibility, and leveling > such claims doesn't seem constructive to me. > > I can understand the frustration (ie, "fix it now!"), but fixing such issues > is often complex, and doing it properly is the only sane way forward. For > better or worse, that's simply a big job and a lot of work to be done (on > all sides... testers, triagers, pkg maintainers, upstreams). Rex, Agree that doing it properly is usually the right way to proceed, rather than a quick hack. But a little voice inside my head wonders why pulseaudio cannot code a little more defensively around its calls to alsa lib functions, (in this case snd_pcm_mmap_playback_avail), to deal with the buggy numbers returned that currently send it into an infinite loop and shutdown. An audio glitch and a log message would be infinitely preferable to pulseaudio shutting down and needing to be restarted. Yes, the bug is further up the chain from pulseaudio, but as it is pulseaudio that is first in the firing line for any Fedora audio issue...... P.S. This is not a criticism of pulseaudio. I think it's great software. The ability to move streams between audio hardware and networked audio, make it a winner as far as I'm concerned. So please excuse me if I'm speaking out of turn. Regards Clive - Clive Messer <clive@xxxxxxxxxxxxxxxxx> -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
