On Sat, 23 Jun 2007 09:08:26 +0200
Joost Yervante Damad <[EMAIL PROTECTED]> 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
> 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.
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'.
> 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?
'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.
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.)
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.
HTH, and thanks again for the excellent help.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
