libxine and audio cd: use libcdio ?
avg at freebsd.org
Thu Dec 2 16:42:25 UTC 2010
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:
- 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
- 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?
P.S. I've also written a little posting about differences between cd(4) and acd(4)
with respect audio CDs:
More information about the freebsd-multimedia