Subject: Re: [linux-audio-dev] opinion sought re: cdda2wav & cdrecord
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Oct 04 2000 - 15:20:06 EEST
>i've actually written a Perl script to copy^H^H^H^Hbackup CDs in exactly
>this manner, using FIFOs as the intermediary between cdparanoia and
>cdrecord. the technique works remarkably well, especially when you look at
>what's happening in the process list :). i eventually want to extend the
>script to work in disc-at-once mode when (if?) cdrecord ever supports that,
>and to handle different song gap situations. (there's currently no way i
>can tell how long the 'gaps' are between songs.)
cdrecord does both of these now, but only on h/w that can support it.
>is there a _real_ need to do this without fork/exec/pipe? they're
>reasonably efficient processes under Linux, so maybe you don't really need
>to go to all the trouble of doing it in one process.
the problem is that when you do this in a GUI with real-time metering,
some potential low-latency issues, and so on, mixing up both threads
and fork() leads to some complications that make the code harder to
understand and more importantly, it becomes necessary to deal with
more subtle race conditions.
the other big problem, which is not actually an issue for any reason
other than elegance, is that there is no way to control the amount of
buffering between two processes that use a pipe. pipes have a fixed
size, and unless the two data rates match each other precisely, the
pipe will tend to fill up, creating a larger buffer between them than
may be desirable. however, i don't think that this matters, since as
long as we stop the audio thread from feeding the pipe *to* cdrecord,
and we stop it from reading the pipe *from* the ripper, things happen
the way that user expects, even if cdrecord or the ripper are still
running for a little while after the relevant button press.
>well, if you want my script (the code says everything), i'll be happy (but
>embarrassed) to distribute it to the list. it hasn't been updated in about
>a year, but it basically works for me :). maybe i could save you a bit of
>hacking and just munge the script to do what you want it to do.
sorry, but the hacking is already done. and its a lot more complex
than the situation you're dealing with, because (1) there is a GUI
that is intended to show what is going on exactly that point in time
and (2) i have to stream data from an audio interface as the source
for cdrecord and to the audio interface as the destination for the
ripper. so its really quite a different kind of situation. but thanks
for the offer. try to keep in mind that the goal in this situation is
driven by the desire (need?) to model the capabilities of real h/w
recorders: i'm not trying to just find a mechanism for copying CDs.
and in fact, *most* people with computers will record the audio to
disk first, then burn it later, and i am *very* happy using gcombust
for that.
--p
This archive was generated by hypermail 2b28 : Wed Oct 04 2000 - 15:39:25 EEST