Red Hat Bugzilla – Bug 710927
Short garbled noise at the beginning when playing a midi file
Last modified: 2012-08-08 11:30:54 EDT
Description of problem:
When timidity starts to play a midi file, in the first second some garbled sound is heard. Since it is different each time, I assume it is some kind of uninitialized data.
Additionally there are some error messages about wrong channels printed out by the pulseaudio libs, which seem to contain also only binary garbage.
Version-Release number of selected component (if applicable):
100% - I could reproduce this on two different systems.
Steps to Reproduce:
1. play any midi file with timidit
- garbled sound at the beginning (just one second or less)
- error message containing some random binary data:
ao_pulse ERROR: Unrecognized channel name "�#���#��" in channel matrix "�#���#��"
ao_pulse WARNING: Input channel matrix invalid; ignoring.
MIDI file: /tmp/tmp4UZPeT.mid
Format: 1 Tracks: 1 Divisions: 96
Any news on this issue?
The problem appears to be related to processing of MIDI events of type ME_EOT. Fields "channel", "a" and "b" are not initialized for such events. However, "channel" is accessed in play_event(). Valdrind warns about it. I was able to fix the clicks, but I don't quite understand the code to send the patch yet.
I was wrong, it's an unrelated issue. I make an RPM from the current CVS timidity, and it doesn't exhibit the problem. I had to disable almost all patches as they didn't apply. However, timidity++-2.13.2 recompiled as an rpm without those patches does make the clicks. Thus, the fix is in timidity CVS.
I'm importing timidity into git to do a binary search for the fix. But maybe the maintainers should consider packaging the CVS version? There have been no timidity releases for years.
Created attachment 531892 [details]
Fix for the clicks in the beginning of output
I used git bisect to find the commit that fixed the clicks. It turned out to be a patch by Keishi Suenaga <email@example.com>
* timidity/effect.c: Noise shaping noise fix.
I rebuilt the package with this patch. and the clicks are gone. The messages starting with "ao_pulse" are unrelated.
Pavel, thanks for the investigation!
I can confirm that this patch will fix the issue for me (tested in F16). Great!
@jnovy: Since the issue affects all users of my package "solfege" (the program is not usuable since you'll here the garbled sound constantly), I would like to get this issue fixed in timidity++ soon. I would like to help out here, so if you don't have any objections, I can either "provenpackage" it or it would be probably better if you could approve my request as co-maintainer for timidity++.
Christian, ACLs for you seem to be approved so feel free to fix it if you wish. Thanks to Pavel for the patch!
Jindrich, thanks! New packages for rawhide, F16 and F15 are currently building.
timidity++-2.13.2-25.fc16 has been submitted as an update for Fedora 16.
timidity++-2.13.2-25.fc15 has been submitted as an update for Fedora 15.
The packages are fine. The link from https://admin.fedoraproject.org/updates/timidity++-2.13.2-25.fc16 to http://koji.fedoraproject.org/koji/search?terms=timidity++-2.13.2-25.fc16&type=build&match=glob is wrong. The pluses should be escaped:
Timidity plays without clicks, but it plays in one ear. That's material for at least three additional bugs (/etc/timidity.cfg in fluid-soundfont-lite-patches has no effect, timidity ignores "-c" unless its standard config file is missing and timidity plays to one channel when using mono soundfonts). Timidity clearly needs some love. Alternatively, somebody should make fluidsynth useful from the command line without tons of options.
(In reply to comment #10)
> Timidity plays without clicks, but it plays in one ear. That's material for at
> least three additional bugs
> (/etc/timidity.cfg in fluid-soundfont-lite-patches
> has no effect
I see you've filed bug 752167 for this, I explain in detail there why this is not a bug, but rather a feature if you want to use timidity++, you should also have
fluid-soundfont-gm installed, and this is insured through rpm dependencies, for details see bug 752167.
> timidity ignores "-c" unless its standard config file is missing
From the manpage:
-c file, --config-file=file
Reads an extra configuration file.
So if you mean by ignores, still complains about missing soundfont file from the default config then again not a bug.
> and timidity plays to one channel when using mono soundfonts).
This could very well be true, but only when using GUS format patches. This was likely not noticed before since no one is using timidity++ with GUS format patches now a days. You could file a bug for this, but without a patch to fix it I doubt anyone will get around to fixing it, given that it does not impact normal use of timidity++
> Timidity clearly needs some love.
It could indeed use some more active maintenance, but it is not as bad as you may think :)
Actually, the problem is the other way around. I get sound in only one ear with FluidR3_GM.sf2, but not with fluid-soundfont-lite-patches or with TimGM6mb.sf2 that comes with mscore. FluidR3_GM.sf2 is the default, and the default is bad.
(In reply to comment #12)
> Actually, the problem is the other way around. I get sound in only one ear
> with FluidR3_GM.sf2, but not with fluid-soundfont-lite-patches or with
> TimGM6mb.sf2 that comes with mscore. FluidR3_GM.sf2 is the default, and the
> default is bad.
Oh, interesting I tried this and I can reproduce (last time I seriously tried timidity I think I was still using an other soundfont). After trying this I spend a long time debugging it, too long really. But I've it "fixed" now.
First of all the problem is not with instruments with mono patches, but actual with instruments with stereo patches, the problem is that for some reason the FluidR3_GM.sf2 does not contain the "link id" properties inside the instrument layer property lists, which link from the left channel sample to its matching right channel sample, without these properties timidity will only play the left samples, on the left channel ...
I've fixed this by adding a workaround to timidity to find the matching samples during soundfont loading and set the link itself.
One part of my too long debugging on this has been to first upgrade the package to the latest CVS code, as that indeed seems like a good idea, and I hoped that would fix the problem (but it did not).
As an end result of all these efforts, I've now started a new timidity++ build for rawhide, based on the latest CVS code + relevant Fedora patches rebased (and a lot of them dropped) + this sf2 loading fix. The difference in how a midi file sounds between the old code with the bug and the fixed code is enormous. So we should fix this for F-16 too.
I've run out of steam (and time) for this so I hope someone else can do the F-16 work, I see 2 options for F-16:
1) Just do a git merge origin/master and build what we've in rawhide, the downside of this is that we drag in quite a few changes possibly causing issues, then again so far no-one has spotted the quite big issue with our default setup, so I'm not sure how much testing we will actually loose if we do this; or
2) Drop patch 0009-... from rawhide into the F-16 package (may need some porting) this will fix the stereo instruments only playing on one channel problem without dragging in any other changes.
The second approach is fine with me. I just did it locally in F16. No porting is needed whatsoever. I'm enjoying MIDI in stereo now! Thank you very much! Please make the fixed packages for F16 and F15!
F15 is also OK with just the 0009 patch. I also checked MIDI files that played in stereo before, such as /usr/share/kde4/apps/kmid/haendel_hallelujah.mid - they still sound great.
Hans, Pavel, I agree that the 2nd option would be the better one. I've created new packages for F15 and F16 and verified, that the issue with playing only on one channel is fixed.
timidity++-2.13.2-25.fc16.1 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
timidity++-2.13.2-25.fc15.1 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Hans, now that your fix for sf2 loading has passed testing, it would be nice to send it upstream. I'm not sure if there are any active timidity developers, but the mailing list firstname.lastname@example.org is still getting new messages. Also, maybe a bug against fluid-soundfont is needed.
(In reply to comment #19)
> Hans, now that your fix for sf2 loading has passed testing, it would be nice to
> send it upstream. I'm not sure if there are any active timidity developers,
> but the mailing list email@example.com is still getting new
Already on it, AFAIK timidity upstream is dead, but I'm trying to form a new upstream together with the Debian timidity maintainer, see:
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
The bug is actually fixed, but no human being bothered to close it, so the robot did it.