Bug#428353: timidity: ALSA lib pcm.c:2105:(snd_pcm_open_conf) Cannot open shared library...
On Wed, 27 Jun 2007 14:18:49 +0200
Joost Yervante Damad <andete@debian.org> wrote, in part:
> > I tried a hint from:
> >
> > http://pulseaudio.org/wiki/PerfectSetup#TiMidity
> >
> > ...and ran it like so:
> >
> > timidity -Oe foo.mid
> >
> > That worked right, which seems odd, since 'esd' jobs are sent to
> > 'pulseaudio'.
>
> Yeah, thats very odd. I would expect that timidity with alsa as
> output device would just work in this setup.
I just now tested it without the '-0e' switch again a few times. The
first three times it played fine. The fourth time it did the odd thing
again, played a note, then silently maxed the CPU. Perhaps it's a
cumulative bug; it couldn't be the command line 'timidity', once
unloaded it has no way to control a future instance. The underlying
'pulseaudio' code stays in memory however.
Later I'll try more tests, and try to get it to reproducibly occur.
> Installing works fine, see below. It is the upgrade or re-install
> when the timidity daemon is enabled and alsa is configured for
> pulseaudio that fails. A subtle but important difference :)
It helps. My usage of the verb "install" was the same as the
loose 'apt-get install' usage, (that is, either a fresh install or a
reinstall); a bit vague in the present situation.
> The default installation of timidity doesn't enable the systemwide
> daemon. With this setup you can convert files just fine, even without
> a soundcard. I assume you enabled it at some point
> in /etc/default/timidity . If you don't use the systemwide timidity
> sequencer, than just disabling it might solve your problems. Enabling
> the systemwide deamon assumes some form of audio output device is
> available (as is configurable in /etc/default/timidity).
Yes, I had enabled it at some point.
If now I understand correctly, the reinstall fails because the daemon is
enabled and can't find a sound device. Based on that, it follows that a
new install would also fail on on a system with no sound card, if the
user enabled the daemon. If that's true then the verb "install" can be
used again, with the qualification that it strictly would mean "new
install, with daemon on".
Should such installs and upgrades depend on the daemon? Obviously if a
user requested daemon can't acquire some needed resource, there ought
to be an error message, but it's not as obvious why the resulting
error should break the (re)install.
To put it another way, suppose for the sake of illustration, (I'm not
advocating this), 'timidity' was split into two packages,
'timidityp' (the command line program) and 'timidtyd' (the daemon).
If the daemon couldn't start, that error ought to break a
hypothetical 'timidityd' install, but it shouldn't break 'timidityp'.
Next we combine the two imaginary packages in a single package.
When one half fails, what should happen?
Current behavior, only install if:
p and d
OTOH, consider:
p and ( d or not d )
...which reduces to:
p
> > '3)' might better be done by another package closer to the
> > trunk of the 'pulseaudio' package tree. I don't understand why
> > the various 'pulseaudio' installation scripts didn't take care of
> > these group permissions earlier.
>
> Well normally you want to run as few stuff as root as possible.
Agreed. Let me modify the implicit question to ask whether it's
possible to get 'pulseaudio' to work with 'timidity' without root
access, and if so, do you suppose the various 'pulseaudio'
installation scripts could (in theory) be made to correctly configure
that?
Maybe this reply has too many questions. Anyways, thanks for the
clarifications and debugging hints, and HTH...
Reply to: