Summary: | media-sound/madplay-0.15.2b-r1 may monopolize ALSA sound devices | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Phil Stracchino (Unix Ronin) <phils> |
Component: | New packages | Assignee: | Gentoo Sound Team <sound> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Phil Stracchino (Unix Ronin)
2010-01-15 02:37:07 UTC
While rather unrelated, I think following procedure similar to one described here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006314.html may give some useful input for this bug. I don't at this moment remember what the exact problem was, but I could not get madplay and pulseaudio to play nicely on this sound hardware. That pretty much precludes this method of diagnosis. If I remember rightly, madplay and PA were fighting over the device; if madplay was playing, PA couldn't start, while if PA was running, madplay couldn't play. (madplay does not have pulseaudio support.) The only way I managed to get madplay working non-exclusively on ALSA on this sound hardware was to run esound AND pulseaudio, and rebuild madplay with esd support, but that combination was horribly unstable - esound would stop responding about every 20 to 30 minutes. I'd switch to mpg123, except that madplay sounds so much better, and mpg123 falls over when the system is heavily loaded. |