Re: cdrtools cdrecord/cdrecord.c
Hi Joerg,
> > Would there be volunteer testers for a united cdrecord
> > compatibility wrapper based on libburn for CD and
> > growisofs for DVD ?
>
> The last time I checked libburn, it was a complete desater.
> The first time where a project turned unmaintainable short
> after it's creation.
It's not all that bad, currently. :))
Let me take the occasion to show to you the due politeness and
respect by informing you in advance about my upcoming cdrecord
compatibility wrapper around libburn: cdrskin .
It is not much announced yet because it still depends on a
slightly patched libburn. I am negotiating with Derek Foreman
about how to include the patches into his code.
... google ... it already begins to sprout. (What is a Gentoo ebuild ?)
I took some effort to make clear that cdrskin is not cdrecord.
("Do not bother Joerg Schilling" et al.)
It has to issue some cdrecord-like text messages though, in
order to be compatible enough to serve the cdrecord frontends.
The documentation is supposed to make clear that these are
quotations from your work and the standards which you did set.
A problem is that the frontends want to see some words
like "Cdrecord" and "Copyright" in order to recognize a
program as cdrecord compatible. So i have to issue something like
cdrskin 0.1.1 : limited cdrecord compatibility wrapper for libburn
Cdrecord 2.01-Emulation Copyright (C) 2006, see libburn + cdrskin
After K3b made from this line out of cdrskin's first -version text
"Cdrecord-Emulation 2.01 Copyright (C) 2006 Thomas Schmitt"
the following text line
"Using cdrecord 2.1 - Copyright 2006 Thomas Schmitt"
i even removed my name from that -version text to avoid any further
embarrassing frontend postprocessing. Now K3b can only versify:
"Using cdrecord 2.1-Emulation - Copyright (C) 2006, see libburn + cdrskin"
which is clear enough, i hope.
Give me a note if you see any undue ambiguity remaining.
> > Isn't there anybody in the world who did not make his own fifo ? :o)
>
> I did since 1987....
I use that one since 1997. It saved me from lots of misburns.
> Be careful, most "pthreads" programs that have been developed on Linux
> do not run elsewhere because Linux is not very standard compliant.
In this special case it is only to cope with the threads
initiated by libburn. So Linux-centricicsm would be ok,
for once.
> If you are looking for a general purpuse fifo code, check the fifo
> code from star. It is extremely mature (as it is" on" by default
> since 15 years) and it is higly portable.
It never let me down and it surely is optimized for effectivity.
But i have to flange my fifo at the input of libburn and
may not insert it between the reader function and the writer
function. Additionally i believe three threads are enough. So
i want to keep the fifo entirely within the supervisor thread.
This becomes a little demanding for handling multiple tracks.
The fifo has to handle several pairs of input-output channels
sequentially. When track #1 closes it has to begin to buffer
track #2 while it continues writing #1. Later it has to close
the outlet of #1 and open the outlet of #2. So libburn believes
these are two separate files on disk.
To test this whole complicated setup i made the fifo handler able
to serve several fifo objects simultaneaously (select(2) is one
of the bestest calls ever). So one fifo can play libburn + burner
and the other fifo plays cdrskin + itself. Single threaded.
Much better debuggable than the real run with libburn.
The transaction size is only 2 kB so it does not block on
writing into the pipes which are read as 2 kB blocks by
libburn.
This all is not very economizing on CPU - but CPU seems not
to be the bottleneck with system throughput currently.
I mainly miss an opportunity to write a stream of
unannounced length into stdin like with cdrecord -tao .
For any other of my personal demands cdrskin is sufficient
now. I use it for my CD backups since about six weeks.
Audio will become quite a challenge, i guess. If ever.
Have a nice day :)
Thomas
Reply to: