Bugzilla Bug 192579

media-libs/libdts is deprecated and apps should be using libdca now, renamed by
upstream so moving on.. please do xine-lib-1.1.8 bug same time with this one,
as current stable doesn't support libdca. thanks.

Site http://www.sr.se/cgi-bin/mall/index.asp?programid=2445 has some example
DTS files you can use for testing.

media-libs/libdca-0.0.5 on AMD64:

Emerges fine, no collisions. Works, tested with
media-video/mplayer-1.0_rc1_p20070824 with dts USE flag and the included dtsdec
program.

Portage 2.1.3.9 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r4,
2.6.23-rc1 x86_64)
=================================================================
System uname: 2.6.23-rc1 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
Timestamp of tree: Sat, 15 Sep 2007 13:00:01 +0000
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="collision-protect distlocks metadata-transfer multilib-strict sandbox
sfperms strict test unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/
http://distro.ibiblio.org/pub/linux/distributions/gentoo/
http://www.gtlib.gatech.edu/pub/gentoo "
MAKEOPTS="-j3"
PKGDIR="/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X aac acl alsa amd64 berkdb bitmap-fonts cli cracklib crypt cups dbus dri
examples flac fortran gdbm gpm hal iconv isdnlog jpeg kde kdeenablefinal mad
midi mmx mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam
pcre perl png pppd python qt4 readline reflection session spl sse sse2 ssl
symlink tcpd test truetype truetype-fonts type1-fonts unicode vorbis xml xorg
zlib" ALSA_CARDS="usb-audio hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy
dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear
meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU"
VIDEO_CARDS="nvidia"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Hmm, why does media-libs/libdca block media-libs/libdts, but not the other way
round?

amd64 stable

(In reply to comment #3)
> Hmm, why does media-libs/libdca block media-libs/libdts, but not the other way
> round?
> 

Because Portage can handle reverse blockers I believe.

Stable for HPPA.

x86 stable

On Sparc, this builds and installs routinely.  However, it has no built-in
tests and I have no way to test it, so I myself cannot keyword it without some
help.  From the description, I suppose this would be verification as a libdts
replacement.  But that doesn't help because my systems have no use for
supporting soundstreams --- no audio support.

ppc stable.

(In reply to comment #8)
> On Sparc, this builds and installs routinely.  However, it has no built-in
> tests and I have no way to test it, so I myself cannot keyword it without some
> help.  From the description, I suppose this would be verification as a libdts
> replacement.  But that doesn't help because my systems have no use for
> supporting soundstreams --- no audio support.
> 

In order to test it you can grab samples at : 
http://samples.mplayerhq.hu/A-codecs/DTS/

I've patched vlc 0.8.6b_beta1 to be compatible with this version, so you can
just try USE="dts" emerge vlc and then run "vlc your_just_grabbed_dts_file"

you can also try dcadec that is shipped with libdca, "dcadec -o wav my_dts_file
> foo.wav" and then just play it with your favorite audio player ;)
(betware of the ">", it outputs binary to stdout and made unusable my $TERM
several times)


(copy/paste from bug #175164)

Um, my main point was that I do not have audio devices in any of my systems. :)

(In reply to comment #11)
> Um, my main point was that I do not have audio devices in any of my systems. :)

Bah... I missed the 's' ;) shame on me

Then I dunno how I could help you, besides providing you md5's of decoded wav
files to mimic a test.

Going through the dcadec procedure you suggest with a file from
http://samples.mplayerhq.hu/A-codecs/DTS/ runs and produces an output file. 
I'm going to play with the resulting file on a system with good sound support. 
It's just that that system is not sparc --- that doesn't matter, I think. 
Surely the resulting .wav file from "dcadec -o wav ... > ..." is
system-neutral.

I don't need sound on the system where I make the file; the file I make has to
play on a system with sound. :)

sparc stable

If media-libs/libdts is deprecated, you need to stabilize
>ffmpeg/ffmpeg-0.4.9_p20070330 since this version has a dependency on
media-libs/libdts.

alpha/ia64 stable, thanks Tobias

ppc64 stable

Ok.If libdts is deprecated, I understand now why package with the dts USE flag
enabled try to install the dca package. But then I guess in this context, there
should be a new "dca" USE flag. Of course "dts" should still exist for a while
and continue to redirect to dca for compatibility for current portage's
configuration. But a "(deprecated: use dca now)" should be add to its
description.

(In reply to comment #18)
> Ok.If libdts is deprecated, I understand now why package with the dts USE flag
> enabled try to install the dca package. But then I guess in this context, there
> should be a new "dca" USE flag. Of course "dts" should still exist for a while
> and continue to redirect to dca for compatibility for current portage's
> configuration. But a "(deprecated: use dca now)" should be add to its
> description.
> 

imho we should only update the use flag description, dts is a format afaik,
thus dts useflag makes sense.
but the description might be a bit confusing:
dts - Enables libdts (DTS Coherent Acoustics decoder) support

I'd suggest changing it to:
dts - Enables DTS Coherent Acoustics decoder support


@other sound people: any thoughts ?

This sounds ok for me.

Oh a question that I wondered after I made some search about what was precisely
this DTS Coherent Acoustics technology (thanks Wikipedia ;-). Apparently libdca
is not another library providing same service, but the new name of the libdts
library. In this case, isn't there a mean through portage that -- even though
they have different names -- libdca can be considered as an upgrade of libdts?

The reason of this question is that as libdts was already installed, libdca's
installation was blocked by presence of libdts. I had then to unmerge it first
(so 2 steps instead of one and some time checking dependencies, and wondering
what was exactly this library). So I was thinking that maybe portage could do
it itself if there could be some flag telling it that this is simply a name
change...

But maybe is it difficult if the name change was also accompanied by some API
change? Or maybe simply dependency problems because any build before and after
the upgrade would look for different named library (but for this, if API is
similar, I was thinking that some symlink could solve the issue, could it?)?
Bye.

yes, we can do a packagemove so that it can be considered as an upgrade; but if
we do so, that'll probably break arm and sh stable systems since they don't
have any libdca stable. (please correct me if I'm wrong on the packagemove
behavior though)

(In reply to comment #19)
> I'd suggest changing it to:
> dts - Enables DTS Coherent Acoustics decoder support
> @other sound people: any thoughts ?

I've just changed it per your suggestion. Just do it(tm) ;-)

arm stable