If you use a LADSPA plugin in your ALSA configuration (e.g. http://gentoo-wiki.com/HOWTO_Set_up_a_system-wide_equaliser_with_ALSA_and_LADSPA) then Timidity will fail to load when called from /etc/init.d/timidity because it can't open an ALSA device. The reason it can't open an ALSA device is because it can't find the LADSPA plugins that ALSA has been configured to use. The path is stored in /etc/env.d/60ladspa, which sets the LADSPA_PATH environment variable. If this environment variable hasn't been set, nothing can open an ALSA device (even aplay fails.) I fixed this by adding "LADSPA_PATH" into /etc/conf.d/env_whitelist which made sure the environment variable was available for initscripts, and this allowed /etc/init.d/timidity to start Timidity successfully. There's probably a better way of doing this, but either way the LADSPA_PATH variable needs to be present when loading Timidity (or any ALSA program for that matter.) Reproducible: Always Steps to Reproduce: 1. emerge timidity 2. Add a LADSPA plugin to the default ALSA PCM device 3. Run "/etc/init.d/timidity start" and observe its failure Actual Results: Timidity was unable to open an ALSA device Expected Results: Timidity should have opened the ALSA device and daemonised successfully.
Is this still a problem with -r8, or -r9? I've changed init script a bit for other bug, which included a change from group nobody to group audio. I suspect it is still a problem, I think I got it, trying to figure something out..
+ 24 Jul 2009; Samuli Suominen <ssuominen@gentoo.org> + +timidity++-2.13.2-r11.ebuild, +files/conf.d.timidity.2, + +files/timidity.desktop.2: + LADSPA_PATH is now configurable from inside conf.d/timidity wrt #204713, + thanks to Adam Nielsen. Revert -polling.patch since it breaks realtime + playing with FluidR3 soundfont wrt #275198. Desktop entry now prefers GTK+ + frontend if available wrt #207311.
