Subject: [linux-audio-dev] opinion sought re: cdda2wav & cdrecord
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Oct 03 2000 - 21:49:16 EEST
ok, well my real-time CD recorder project turned out to be more
involved than i thought, mostly because i forgot that to model a
dedicated h/w box, i needed to rip the audio of the CD for playback
and feed it back out of whatever audio interface was being used for
input. or that this should at least be an option.
so, i extended the hack by which i used cdrecord via a pipe, and
started using cdda2wav for the same thing. and it now works. its
nice. there will be more work to do handling CD TOC's, track markers
etc. but thats gravy, i think, compared to basically getting it to
work.
but here's the thing: the code is a lot uglier having cdrecord and
cdda2wav be separate processes. i have to set up pipes, handle the
fact that some CD players can't supply data at < 2x speed, etc. etc,
all via these subprocesses. worst of all, to make the GUI responsive,
i have to actually do all this from a non-gui thread, and then notify
the GUI when things are done. this is all done, and its fairly clean,
but there is a distinct sense in which its more tricky than it need
be.
my gut instinct tells me that i should take the mass of code that
comprises cdrecord and cdda2wav and merge them into this project,
running their code in their own threads, but without a fork()/exec()
and a pipe() in the way.
the downsides, however, are obvious: updates to cdda2wav and cdrecord
then need source-level munging to catch. also, the process of merging
them is likely to be quite unpleasant. there is nothing in either
program to suggest that it has ever thought of being used in this
way.
so, does anyone here have any opinions on this question ?
--p
This archive was generated by hypermail 2b28 : Tue Oct 03 2000 - 22:23:56 EEST