Description of problem: I can use timidity to play a midi file and it when doing so it appears in the playback tab as "libao[timidity]". However, when invoke it as "timidity -iAD" so that it can be a midi server for tuxguiter", I have a number of problems: 1) it fails to start because the snd sequencer device isn't available. I can correct this by doing a modprobe snd_seq. 2) I start it with '-iAD'. The pulseaudio volume control playback tab seems to briefly flash like timidity will appear, and then it disappears. In FC10 the timidity midi server would appear allowing me to verify it had started and connected to pulseaudo. I start up tuxguitar and try to play the sample file, but no sound comes out. This works for me in FC10. Version-Release number of selected component (if applicable): timidity++-2.13.2-18.fc11.x86_64 How reproducible: Every time after startup of machine Steps to Reproduce: 1. start timidity with '-iAD' 2. 3. Actual results: no sound Expected results: sound Additional info: timidity -iAD TiMidity starting in ALSA server mode ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory error in snd_seq_open
Some more information. The problem seems to be when I start timidity as a daemon: "timidity -iAD". After starting tuxguitar I will get this error on the console: timidity: pulse.c:200: pulse_new: Assertion `p->context' failed. If I start it as "timidity -iA" I get sound. Also the pulseaudio volume window *does* show an entry, but only when tuxguitar is connected.
This also affects Fedora 11 (FC11), as follows: As a normal user: [daddy@moses ~]$ timidity -iA [WARN 18065] polkit-session.c:144:polkit_session_set_uid(): session != NULL Not built with -rdynamic so unable to print a backtrace TiMidity starting in ALSA server mode ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory error in snd_seq_open [daddy@moses ~]$ As root: [root@moses ~]# timidity -iA Couldn't open output device [root@moses ~]# Whereas on Fedora 8, timidity would just run as a midi synth daemon from the same command. It was suitable for getting rosegarden4 going. I have: timidity++-2.13.2-18.fc11.i586 kernel-PAE-2.6.29.3-140.fc11.i686
Hi, I'm afraid I'm not all that familiar with the server mode of timidity. Can one of you please give me a step by step (command by command) recipe for using it, and for reproducing this problem, including how to launch a client and make it actually play some music.
1) Get tuxguitar from the repos and install it. 2) start timidity in ALSA server mode: "timidity -iAD". This will put it into the background. 3) start tuxguitar and in Tools->Settings->Sound->Midi Port, you need to select one of the "Timidity Port"s to use timidity 4) tuxguitar has a sample file automatically loaded so press play. You will see that the timidity server will immediately crash with the assertion error. If you started timidity like "timidity -iA" which keeps it in the foreground, you will see that following the tuxguitar steps above will result in sound.
Please note that I am seeing slightly different symptoms from bike_head. I just haev to start timidity as a normal user onmy fully up to date fc11 P4 system to get the error message; there is no need to run any data through timidity: $ timidity -iA [WARN 1833] polkit-session.c:144:polkit_session_set_uid(): session != NULL Not built with -rdynamic so unable to print a backtrace TiMidity starting in ALSA server mode ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory error in snd_seq_open $ rpm -qa | grep timidity timidity++-2.13.2-18.fc11.i586 $ Hope that clarifies things.
(In reply to comment #5) > Please note that I am seeing slightly different symptoms from bike_head. > I just haev to start timidity as a normal user onmy fully up to date fc11 P4 > system to get the error message; there is no need to run any data through > timidity: > > $ timidity -iA > [WARN 1833] polkit-session.c:144:polkit_session_set_uid(): session != NULL > Not built with -rdynamic so unable to print a backtrace > TiMidity starting in ALSA server mode > ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file > or directory > error in snd_seq_open > > $ rpm -qa | grep timidity > timidity++-2.13.2-18.fc11.i586 > $ > > Hope that clarifies things. Hmm, this works fine for me. When I start tuxguitar with the settings mentioned a "libao output (null)" shows up in the pavucontrol playback tap, and playing the guiter notes works fine (and the volume can be controlled using the slider for "libao output (null)"). Maybe this was fixed by a recent update? Can you please try to update to the latest rawhide (F-11 candidate) tree and try again ? Also if things still fail, please give me the output of: rpm -q timidity++ libao pulseaudio alsa-lib
Still same symptoms today (fully up to date F11). I have: $ rpm -q timidity++ libao pulseaudio alsa-lib timidity++-2.13.2-18.fc11.i586 libao-0.8.8-6.fc11.i586 pulseaudio-0.9.15-11.fc11.i586 alsa-lib-1.0.20-1.fc11.i586 $ on Linux moses.localdomain 2.6.29.3-155.fc11.i686.PAE #1 SMP Wed May 20 17:31:09 EDT 2009 i686 i686 i386 GNU/Linux
Ok, I've managed to reproduce this now and I know whats going on. This seems to be a conflict between how timidity works and recent changes to pulseaudio to detect pulseaudio abuse from programs using fork. In this case however I believe there is no such abuse, but that pulseaudio's fork detection is being overzealous. So I'm changing the component to pulseaudio. Lennart, As you can see timidity hits an assert in the pulse_new() method of the alsa pulseaudio plugin. This is caused by pa_context_new() returning new, which in turn (I believe) is caused by the fork detection. Here is what timidity does: 1) Start 2) autodetect what sort of output to use. This does an snd_pcm_open(), to see if alsa will give it a pcm followed by an snd_pcm_close() 3) More initialization including fully initializing alsa output 4) As it has been told to run as a midi server, it closes the alsa output again (using snd_pcm_close()), so that it won't get in the way of other programs who want to use the sound card while it waits for midi clients to connect 5) fork, the child continues to run, the mother exits with a 0 status 6) Now when a midi client connects it tries to open the alsa output again, doing an snd_pcm_open() and further initialization, this triggers the assert in pulse_new() So the fork detection code is correctly detecting a fork. But doing so in this case seems unwanted behaviour. What timidity does is; 1) create pa context 2) destroy pa context 3) fork 4) in the child: 5) create pa context Since the child creates its own new fresh pa context, the fact that a fork has happened should not be an issue IMHO, perhaps this can be fixed by making the pid used for fork detection part of the context struct ?
Hans, even that kind of forking is not supported, because we initialize static mutexes and stuff. Applications that fork after initializing 3rd party library are simple broken. The only issue that should be fixed here is that we shouldn't hit an assert. Which I think is a bug in timidity?
(In reply to comment #9) > Hans, even that kind of forking is not supported, because we initialize static > mutexes and stuff. > Ok, changing component back to timidity then. I'll take a stab at fixing this at the timidity level. Workaround for now: Use timidity with -iA instead of -iAD > The only issue that should be fixed here is that we shouldn't hit an assert. > Which I think is a bug in timidity? No, the assert comes from alsa-plugins-pulseaudio.
Thanks for looking at this problem, guys. However, I thought that would just point out that doing: timidity -iA is not a work-around; it gives the errors shown in 'Comment #5'. I wonder if there are at least 2 separate bugs here?
Ok, I've created a patch to timidity to fork before initializing alsa, which fixes this for me. I'm submitting an update to updates-testing, the update system will post a comment here when it becomes available in updates-testing including testing instructions. In the mean time you can get it here if you want: http://koji.fedoraproject.org/koji/buildinfo?buildID=104630
timidity++-2.13.2-19.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/timidity++-2.13.2-19.fc11
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've installed and tested the update on a fresh install of fc11 on a x86 machine and it does fix the forking problem. However, unless I do a modprobe snd-seq first I will get an error about the /dev/snd/seq not being found. Is this intentional? Remember this is a fresh install as of today.
(In reply to comment #15) > I've installed and tested the update on a fresh install of fc11 on a x86 > machine and it does fix the forking problem. > > However, unless I do a modprobe snd-seq first I will get an error about the > /dev/snd/seq not being found. Is this intentional? Remember this is a fresh > install as of today. No, that is a bug too, but one I haven't gotten around to looking at yet (and most likely not a bug in timidity). Can you file a new bug for this please (use timidity as component for now) and assign it to me. Then I'll look into this as time permits. Thanks.
I filed a bug against timidity [Bug 501051] and this comment sheds some light on the required modprobe: "I needed to uncomment a line in /etc/modprobe.d/dist-oss.conf to load those modules.. Appears they're caught up in the "disable OSS" feature of F11." It turns out one has to do a modprobe for snd-seq and snd-seq-oss. I guess the question is which module to file the bug against?
Comment #17: 501051 is *this* bug. What's the number of the new bug, please? Thanks for all your efforts Brian and Hans :)
Sorry. The timidity bug is [501048] which was finally identified as a udev bug and marked as a dup of [505421].
timidity++-2.13.2-19.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update timidity++'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6228
timidity++-2.13.2-19.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Still seeing problems (this?) on latest F11 with all updates and updates-testing installed. Manually loading snd-seq as a module is needed. Then timidity++ seems to work fine, as described in comment 15.
Several sound problems were solved for my when I used: /sbin/modprobe snd-mixer-oss /sbin/modprobe snd-pcm-oss /sbin/modprobe snd-seq-oss I hope this helps...