[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#428353: timidity: ALSA lib pcm.c:2105:(snd_pcm_open_conf) Cannot open shared library...



On Wednesday 27 June 2007 11:56:41 A. Costa wrote:
> On Sat, 23 Jun 2007 09:08:26 +0200
>
> Joost Yervante Damad <andete@debian.org> wrote:
> > ...I reproduced your setup here, with alsa using pulseaudio.
> >
> > The real problem is this: timitidy as system service runs as the
> > "root" user and the "root" user doesn't have a proper configuration
> > for using the alsa pulseaudio plugin as default alsa device.
> >
> > I solved it like this:
> >
> > add this to /etc/asound.conf:
> >
> > pcm.pulse {
> >             type pulse
> > }
> >
> > ctl.pulse {
> >              type pulse
> > }
> >
> > pcm.!default {
> >     type pulse
> > }
> > ctl.!default {
> >     type pulse
> > }
>
> Last March I had it that way, based on the advice here:
>
> 	http://pulseaudio.org/wiki/PerfectSetup
>
> ...but the first 6 lines tended to break certain programs.  I'll try
> again tho'...
>
> > Then add the root user to the pulse-access group:
> >
> > useradd root pulse-access
>
> That syntax 'useradd <username> <groupname>' isn't valid, as per 'man
> useradd'.  After some searching, I found this worked:
>
> 	% usermod -G pulse-access root
> 	% grep 'pulse-access' /etc/group 	# prove it worked
> 	pulse-access:x:119:alfie,root

Yeah, or do "adduser" I always keep switching adduser and useradd ;-).

> > If you now start the systemwide timidity daemon it will work fine:
> > # /etc/init.d/timidity start
> > Starting: timidity.
>
> Yeah, that worked!
>
> > As you can see it is using pulseaudio as underlying alsa plugin...
>
>   { ...stuff deleted, but I had the same results.}
>
> > ...I hope this helps.
>
> It certainly does, which has therefore improved my whole sound system.
> So this would be on my personal "Top 10" for helpful BTS replies --
> thanks very much.

Likewise, I learned from it also :)

> Meanwhile I notice that plain vanilla 'timidity <midifile>' doesn't work
> right.  If I run:
>
> 	timidity foo.mid
>
> The CPU goes up as usual, it plays a few notes, then goes silent, (yet
> the CPU keeps working hard), and 'Ctrl-C' fails, and it needs a
> 'kill -9' to stop it.  With the old blank '/etc/asound.conf'
> it worked.
>
> 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.

> > As you can see this is not a bug in timidity. Maybe I should provide
> > a hint in the README.Debian about this?
>
> I'm in a state of doubt.  Clearly 'pulseaudio' configuration is the
> sufficient cause; but is it a necessary cause?  To put it another way,
> suppose a user's 'pulseaudio' setup is misconfigured -- is it
> satisfactory that that should prevent 'timidity' from installing?

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 :)

> 'timidity' is a useful tool even if there's no speakers plugged in, or
> if some outside bug or mistake is blocking 'timidity' from using the
> audio device.  The man page first and foremost describes it as a midi
> file converter:
>
> 	% man timidity | grep -nA 8 DESC
> 	11:DESCRIPTION
> 	12-       TiMidity++  is  a converter that converts some of MIDI files
> (supported 13-       formats: Standard MIDI files (*.mid), Recomposer files
>  (*.rcp,  *.r36, 14-       *.g18,  *.g36)  and  Module  files  (*.mod))
> into formatted audio files 15-       (e.g. RIFF WAVE).  TiMidity++ uses
> Gravis  Ultrasound-compatible  patch 16-       files  or Soundfonts (*.sfx,
> *.sf2) to generate digital audio data from 17-       MIDI files.  The
> digital audio data  generated  by  TiMidity++  can  be 18-       stored  in
>  a  file  for  processing, or played in real time through an 19-      
> audio device.
>
> The extreme case is a system with no sound card.  Even then 'timidity',
> the data converter could be used to convert 'midi' files to other
> formats, to be copied then played on another device, e.g. burned to a
> CD and played on a boombox.

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).

> Possible remedies:
>
> 	1) Agreed that a README hint couldn't hurt.
> 	2) Allow Debian scripts to install it even if
> 	   there's no audio device.  (Depending on
> 	   the program's design, that may not be feasible.)

They install just fine, see above.

> 	3) The Debian installer could check for 'pulseaudio'
> 	   misconfigurations, and advise the user accordingly; e.g.:
> 		a) check if user is using 'pulseaudio'
> 		b) check for permissions like groups.
> 			i) Fails. Output a useful error:
> 				Error: 'root' needs to be a member of the group...
>
> '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.

> HTH, and thanks again for the excellent help.

No problem ;)

Joost



Reply to: