*** This bug is a duplicate of bug 1793640 ***
https://bugs.launchpad.net/bugs/1793640
Also gutsy and hardy are well past end of life:
https://wiki.ubuntu.com/Releases
So we are now tracking the issue in bug 1793640 instead.
--
You received this bug notification because you are a member
*** This bug is a duplicate of bug 1793640 ***
https://bugs.launchpad.net/bugs/1793640
I've been thinking that since this bug apparently was fixed by 18.04
(and earlier), but then seemingly regressed again in 18.10, that maybe
we should instead have closed this old bug and tracked the current
There was a regression for me too, from kubuntu 18.04 to kubuntu 18.10,
as described here:
https://answers.launchpad.net/ubuntu/+source/alsa-
driver/+question/675670
Basically KDE showed only the dummy output even if everything else
looked right. trying "sudo alsa force-reload" was not working
Then you are commenting on the wrong bug :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/210472
Title:
Timidity daemon doesn't play nice with pulse audio
To manage notifications about this bug go
Also had this problem (no sound) after upgrade 18.04.1 -> 18.10.
I do *NOT* have timidity installed.
alsa force-reload works as temporary fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/210472
Hmm, yes the recent duplicates of this bug seem to be from 18.10. So
there may be a regression in 18.10, or it might just be because the main
person answering bug reports only learnt about this timidity issue this
week.
I've only had time to link 18.10 bug reports to this one so far.
Certainly
Upgraded from 18.04 to 18.10 and lost sound. Sound setting showed Dummy Output.
alsa force-reload would fix it until reboot. Removed timidity-daemon (apt-get
purge) and the problem went away. Apparently pulseaudio and timidity got along
in 18.04 and earlier versions, not exactly sure what
** Changed in: timidity (Ubuntu)
Importance: Medium => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/210472
Title:
Timidity daemon doesn't play nice with pulse audio
To manage
As described in bug
https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1799541 starting
timidity system daemon can prevent PulseAudio from gaining access to one
of the sound cards in ALSA.
I think, a better solution would be to change timidity to run as a user-
specific service, instead of
** Tags added: cosmic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/210472
Title:
Timidity daemon doesn't play nice with pulse audio
To manage notifications about this bug go to:
The only clean solution to this is to run pulseaudio in system mode and
add the timidity user to pulse-access group. This also fixes some other
problems pulseaudio has and effectively stops other apps from grabbing
the soundcard.
This is because by default only the current user, which is also
In the PulseAudio wiki, they suggest to switch timidity output mode to libao
cf. http://www.pulseaudio.org/wiki/PerfectSetup#TiMidity
However, libao output is not built in the Ubuntu executable.
As of Ubuntu Maverick, I worked around this by starting timidity during
the GNOME startup. It seems
I was going to suggest autostarting timidity at login to gnome using a
'wrapper' like alltray (from the package alltray). I use this to start my
(proprietary) printer monitor applet.
The idea is that the wrapper (and timidity running within it) will be killed
along with all other open
Well, just to try things out, I managed to hobble together a pulseaudio
output for timidity, based off of the ESD code already present. It
works, but as #12 says, pulseaudio kills any connection from a user
which does not happen to be the one that starts pulse.
Well, anyways, here's the code for
Mar 20 18:18:44 fish-laptop pulseaudio[26345]: core-util.c: Home directory
/etc/timidity not ours.
Mar 20 18:18:44 fish-laptop pulseaudio[26345]: lock-autospawn.c: Cannot access
autospawn lock.
Mar 20 18:18:44 fish-laptop pulseaudio[26345]: main.c: Failed to acquire
autospawn lock
And at any
We probably ought to change timidity into a user-mode daemon, and have
it autostart on X login. Having it being run on startup seems fine,
though having it get killed on logout is another matter altogether.
http://www.linuxquestions.org/questions/linux-desktop-74/gnome-run-
I have tried what Daniel Ellis has suggested (very nice details!), and
had the same results on Jaunty.
--
Timidity daemon doesn't play nice with pulse audio
https://bugs.launchpad.net/bugs/210472
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I have been testing this on Karmic and so far have come up with the
following conclusions (please correct me if any of these are not
correct):
- Out of the box timidity and pulse audio cannot play at the same time.
- Restarting timidity (sudo /etc/init.d/timidity restart) gets timidity to work
Looks like the -B2,8 argument may cause a 40% CPU usage. Could be another cause
for the issue.
If it's quite common, then I guess it can simply be removed from the
/etc/init.d/timidity script.
People may prefer it to not be run as root, although that's a bit different
topic.
--
Timidity
Another way to fix this might be to have pulseaudio run as a system-wide daemon
instead of a per-user instance. This can be accomplished by changing the
PULSEAUDIO_SYSTEM_START=0 line in /etc/default/pulseaudio to
PULSEAUDIO_SYSTEM_START=1. This should make pulseaudio start before the
timidity
Thanks, restarting timidity also works, but again, the latency will be
worse than before.(a played note gets first red and then you hear the
note, when there is a fast song you do not hear the highlightened notes,
but these which were 0.5 sec. ago) 0.5 doesn't sound much, but in fact,
when you try
Btw, for the moment I use tuxguitar 1.1(the ubunutu package from their
homepage) and I use gervill which is the default sound in tuxguitar now,
no timidity+sound font. It sounds not bad, the latency is ok and there
aren't problems with pulseaudio. Maybe you can give it a try.
The program in question for me is Sibelius, which also has a delay.
Perhaps you can play around with optional switches when restarting
timidity... for example, the manpage for timidity says that the switch
F can introduce a delay. This may or may not solve the problem.
--
Timidity daemon
I believe this is because TiMidity is loaded prior to the Pulseaudio
sound server.
I fixed this problem by restarting the timidity session: sudo
/etc/init.d/timidity restart
After that, all MIDI-out wavemapping worked perfectly, and my program
(in my case, Sibelius 4.x) did not steal focus from
Maybe you can take a look at my bugreport, because this issue still
happens in Jaunty
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/323320
--
Timidity daemon doesn't play nice with pulse audio
https://bugs.launchpad.net/bugs/210472
You received this bug notification because you are
On Intrepid Ibex I have the same problem, timidity does not connect to
pulseaudio. When other music applications work(and they work perfectly with
pulseaudio) i get no sound from timidity in tuxguitar.
When I first start playing a file in tuxguitar(so with timidity), the other
applications
Reproduced here.
Fixed using gborzi's hints (for both login and logout).
Furthermore, I've edited /etc/init.d/timidity and added the line exit 0 in
the beginning,
so it shouldn't start the unnecessary daemon as root.
--
Timidity daemon doesn't play nice with pulse audio
** Summary changed:
- [Hardy] Timidity daemon doesn't play nice with pulse audio
+ Timidity daemon doesn't play nice with pulse audio
--
Timidity daemon doesn't play nice with pulse audio
https://bugs.launchpad.net/bugs/210472
You received this bug notification because you are a member of
28 matches
Mail list logo
