[Xiph-Advocacy] Xiph.Org releases libao 1.0.0, libVorbis 1.3.1, and vorbis-tools 1.4.0

[Monty Montgomery]

Xiph.Org announces the release of libao-1.0.0, libvorbis-1.3.1 and
vorbis-tools-1.4.0. This is a coordinated update of the audio
libraries and tools to deploy improved surround-sound support across
the libraries and toolchain.

libao improvements:

- AO returned to active development
- Added surround channel mapping API and capability
- Updated all drivers on modern installs
- New config file options
- Driver options may be specified in config file
- Support for MacOSX updated to 10.5 and later
- Build in WMM driver rather than using dlopen()
- Added Roar Audio driver
- Added OpenBSD SNDIO driver
- Workaround for ESD non-4096 byte write bug
- Workaround aRts server crash bug
- Workaround for VIA82xx click/crackle bugs under ALSA
- Remove dead/unused drivers (solaris, alasa05, mmsound)
- Numerous patches from multiple downstreams

libvorbis improvements:

libVorbis 1.3.0 was briefly available and an unreleased staging
snapshot. This official release bumps the version number to 1.3.1 to
avoid any possible confusion.

- Optimized/coupled surround support for 5.1 encoding at 44.1/48kHz
- Added encoder control call to disable channel coupling
- Corrected an overflow bug in very low-bitrate encoding on 32 bit
machines that caused inflated bitrates
- Numerous API hardening, leak and build fixes
- Correct bug in 22kHz compand setup that could cause a crash
- Correct bug in 16kHz codebooks that could cause unstable pure
tones at high bitrates

vorbis-tools improvements:

vorbis-tools 1.4.0 is the first official release of vorbis-tools since
1.2.x. 1.3.x was never offered as an official snapshot, though
various versions were widely deployed as patch-sets by distributions.

- Implement corrected channel mappings for all input and playback file types
- Correct an possible infinite loop in WAV input reading code when
header is corrupt
- Implement "disable_coupling" option for oggenc
- Fix Ctrl-C lockup bug in ogg123
- ogg123 directory playback in sorted order
- Add WAVEFORMATEXTENSIBLE support
- More translations
- Add '-' as stdin/out filename in vcut
- Add -lnetwork check for socket in configure
- Remove 'extra' F parameter from ogg123 remote output
- Numerous code and build fixes

Downloads:

The libao 1.0.0 release is available from:
http://downloads.xiph.org/releases/ao/

The libvorbis 1.3.1 and vorbis-tools 1.4.0 releases are available from:
http://downloads.xiph.org/releases/vorbis/

Happy hacking!

Monty
Xiph.Org

[Nikos Chantziaras]

Post by Monty Montgomery
[...]
libVorbis 1.3.0 was briefly available and an unreleased staging
snapshot. This official release bumps the version number to 1.3.1 to
avoid any possible confusion.
- Optimized/coupled surround support for 5.1 encoding at 44.1/48kHz
- Added encoder control call to disable channel coupling
- Corrected an overflow bug in very low-bitrate encoding on 32 bit
machines that caused inflated bitrates
- Numerous API hardening, leak and build fixes
- Correct bug in 22kHz compand setup that could cause a crash
- Correct bug in 16kHz codebooks that could cause unstable pure
tones at high bitrates

I don't see any reference to AuTuV in there. I suppose that means the
patches were not included in the end? I thought the plan was to merge
for 1.3.0.

[xiphmont]

I don't see any reference to AuTuV in there. ?I suppose that means the
patches were not included in the end? ?I thought the plan was to merge
for 1.3.0.

Correct. That was the original plan, nixed in the end to do surround
first instead. The feeling was that RedHat wants to see Ghost
development moving forward, at least in parallel with other things,
and the surround work was more directly applicable to Ghost
development than the AoTuV merge would be. So, the surround work came
first.

So folks know, AoTuV merges aren't just applying a set of patches and
releasing. Even accounting for dealing with code drift, the merges
require alot of code review and understanding why particular changes
have the effect they do. We caught several important code errors in
the AoTuV M2 merge years ago, so we have to be on the lookout for that
again. I don't mean AoTuV isn't good stable code, just that it's
essential to both do due diligence as well as learn from the
improvements.

Monty