Somewhere on the download page you should make *very* clear that audio encoders in general are *very* compiler dependent. To that end, when you approach 1.0 release, you should enumerate known working and broken compilers (including which optimization flags are recommended for each). These checks should probably also be included in the .spec file to prevent people from rpm --rebuilding without checking if they have a broken compiler. I would also recommend you make an effort to supply for download binaries for more platforms such that only developers will need to ever build it from source. The last thing a promising audio format needs is the Internet to be flooded with awful sounding encoded files because people didn't know their compiler was broken. A few distributions (RH 7.1 included) are a release or two behind, leaving most users to download the new releases from your site. As for the maintainers, I wouldn't be too concerned until 1.0 comes out, but when it does you should probably include some strict encoder tests in the distribution. I wouldn't rely on maintainers to notice any subtle quality issues resulting from a flaky compiler. You could also provide a distribution-targeted release which included a few small public domain music samples (or even noise patterns) and a correctly encoded version for byte-wise comparison. -Ryan --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tuesday, August 28 2001, Ryan Mack said:> Somewhere on the download page you should make *very* clear that audio > encoders in general are *very* compiler dependent. To that end, when you > approach 1.0 release, you should enumerate known working and broken > compilers (including which optimization flags are recommended for each).At the same time, regarding a compiler as broken just because you haven't tried it isn't fair either. I think that saying things which are known to cause miscompilation is fine, and even some "known good" mentions are fine, but it needs to be carefully worded as unknown is not automatically bad :)> These checks should probably also be included in the .spec file to prevent > people from rpm --rebuilding without checking if they have a broken > compiler.Something that you touch on further down which would be even better than checks like this is a set of test cases which can be run with a simple make check or make test. Unfortunately, this is a bit difficult to do with audio codecs. [snip]> A few distributions (RH 7.1 included) are a release or two behind, leaving > most users to download the new releases from your site.It's kind of hard to have versions of a program which were released after the distribution's release unless errata/updates are issued for everything, but then you never get around to having time to make releases ;) My $0.02 (for what they're worth) Jeremy -- Jeremy Katz katzj@linuxpower.org | jlkatz@eos.ncsu.edu http://linuxpower.org | Developer, NCSU Realm Kit for Red Hat Linux GPG fingerprint: 367E 8B6B 5E57 2BDB 972A 4D73 C83C B4E8 89FE 392D --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tue, Aug 28, 2001 at 06:57:06PM -0700, Ryan Mack wrote:> Somewhere on the download page you should make *very* clear that audio > encoders in general are *very* compiler dependent.Not actually true. The problem with egcs 2.91.66 was due to an outright compilation bug. Specifically, adding a float to an int and comparing to an int caused it to use a broken insn that forgot to mask off the appropriate FPU flag, resulting in that comparison always being true, regardless of the values being compared. That's not a compiler sensitivity. It's an outright bug (and was fixed, ironically, two weeks after RedHat shipped 2.91.66, which was an unreleased version, and they continued shipping that bug for more than a year).> To that end, when you > approach 1.0 release, you should enumerate known working and broken > compilers (including which optimization flags are recommended for each).If legit optimization breaks Ogg code, that's an Ogg bug, not a compiler problem.> I would also recommend you make an effort to supply for download binaries > for more platforms such that only developers will need to ever build it > from source. The last thing a promising audio format needs is the > Internet to be flooded with awful sounding encoded files because people > didn't know their compiler was broken.We'd do that anyway if we had the release engineering resources to do so. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.