From owner-freebsd-multimedia@FreeBSD.ORG Thu Dec 2 16:42:25 2010 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0768B10656A7; Thu, 2 Dec 2010 16:42:25 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFFE8FC0A; Thu, 2 Dec 2010 16:42:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08849; Thu, 02 Dec 2010 18:31:35 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CF7C9E6.8090903@freebsd.org> Date: Thu, 02 Dec 2010 18:31:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Max Brazhnikov X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, kde@freebsd.org Subject: libxine and audio cd: use libcdio ? X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 16:42:25 -0000 I've noticed that libxine currently supports digital extraction of Audio CD data only for acd(4) devices, but not for cd(4); the latter case including access via ahci, ATA_CAM or atapicam. This in turn means problems for KDE if Phonon is configured with Xine backend. This is easy to test with kscd or amarok and an audio CD. So I got this craze idea. multimedia/libxine already has a dependency on sysutils/libcdio, but for unrelated reasons. libcdio is a bit more sophisticated than libxine in digital audio extraction area and does properly support both cd(4) and acd(4). So, why not use libcdio's capabilities in libxine instead of rolling duplicate (and less capable in FreeBSD case) routines. This suggestion should probably go to the upstream developers as well. But for time being let's focus on our immediate problem. Here's a work-in-progress and a little bit hackish patch that implements the idea: http://people.freebsd.org/~avg/libxine-input_cdda.diff Short description: - add read_cdrom_toc() and read_cdrom_frames() implementations that use libcdio - universally use cdda_input_plugin_t* as the first argument to read_cdrom_toc - this removes ifdef in the calling code and adds this_gen->fd dereference where needed - an unrelated change that sneaked in - __FreeBSD_kernel__ => __FreeBSD_kernel__, __FreeBSD_kernel_version => __FreeBSD_version - cdda_open => _cdda_open, cdda_close => _cdda_close to avoid name conflict with libcdio headers (cdparanoia compatibility names) - $(LIBCDIO_LIBS) -lcdio_cdda in related Makefile - this is an "unlcean" change, it should be in Makefile.am and should check libcdio availability (like #ifdef LIBCDIO_CONFIG_H in the source code) - also it seems that I missed cdio_cddap_close() call, will fix that. What do you think? Thanks! P.S. I've also written a little posting about differences between cd(4) and acd(4) with respect audio CDs: http://www.listshow.net/201012/freebsd-arch/1747-accessing-data-on-audio-cd.html -- Andriy Gapon