Brian Cameron <[EMAIL PROTECTED]> wrote:
> > Once star is in, it would be a task of minutes to integrate more from the
> > "schily enviroment".
>
> Any information about when star will go in?
It should have been in Solaris 10 GA, it looks like a never ending story....
The include files have been rewritten about a year ago to allow them to be used
from static compile environemnts like the one in ON. I would need some help
with the ON makefile system...
> Well, lets start up the conversation again. I did ping you twice and
> it seemed like you weren't being responsive...but perhaps my emails got
> lost? I think I've already described the interface needs that GStreamer
> has and shared with you an example CDDA GStreamer plugin, so any ideas
> of how to use cdda2wav in such a plugin would be great to hear.
I just reread your old mail and it seems that the library interface you did
report is one of these library interfaces that have been built on top of a
Linux kernel security bug. Instead of reporting the bug, people created GUI
interfaces based on the bug. Later, when the bug became obvious, it has not
really been fixed but the Linux kernel interface was changed so that cdrecord
did not work any longer until I added a workaround.
Currently, linux is definitely not able to deliver reasonable DAE quality from
unprivileged processes. This is because Linux works around the privileges
problem by allowing some (but not all needed) SCSI commands to be issued from
non-privileged processes.
On Solaris, you definitely need more privileges to send any SCSI command and
using the audio related ioctls from any OS gives poor DAE quality.
Note that there are two reasons why it is a bad idea to handle the complete
functionality of DAE in a library:
- cdda2wav has been developed as a program and not as a library.
converting a program into a library is usually not possible at all
or needa a lot of work.
- You need special privileges to do decent DAE.
Note that Eric Raymond some time ago made the proposal to create wrapper code
that behaves similar to a library in such cases. The main problem may be that
the library interface has been designed the wrong way for such a method.
It seems that a lot of code that has been developed on Linux only provides 80%
solutions only.
People who create GUIs in many cases do not have the background skills to fully
understand the taks they are going to present to the users. They often like to
have an interface that is simpler and fits into their way of thinking instead
of listening to the people who did already write CLI software that handles the
problem. Instead of cooperating with the authors that have the needed skills,
other people take parts of the code and create a halfbaken new "product"
claiming proudly: "look it works.....".
If Sun is not trying to create new better solutions but just follows the Linux
line, we will have a lot of software on Solaris that does not get to the
Solaris quality level.
> > This will not work, as most drives work with 60% of the CDs and cdda2wav
> > is the key to raise this number.
>
> I'm assuming there are some drives that have better than 60% playback.
> Perhaps we should let people know what the best drives are, so that
> people can choose the best drives if they want. Thus avoiding problems
> when using CD tools that do not use cdda2wav.
There is only one drive that reads/plays any CD media without using a DAE
program that know how to do it correctly: The Yamaha F1
This drive is out of production since more than 4 years and it is CD only.
Close to that drive, the following Plextor drives may be used:
- Plextor Premium / Premium-2 (CD only)
- Plextor PXW-708
- Plextor PXW-712
- Plextor PXW-755 / 760
Plextor is out of production since more than a year, you I can only give you
hints to historic drives.
> >> 3) Install libcdio from SFE, rebuild SUNWgnome-media packages so that
> >> the cdiocddasrc plugin gets built, and use that. It's not as good
> >> as cdda2wav, but will work with sound-juicer, and is better than the
> >> basic CDDA plugin.
> >
> > This still violates the livenses of the original code (see above).
>
> True, although the license only applies to distributing the code, so
> it might not be a problem for a single-user who just wants to get
> something working for themselves.
Correct, but note that libcdio cannot use anything than the cooked DAE ioctls
from Solaris because of missing privileges. This makes the quality low.
I guess Artems code works in a similar way....
> >> 4) Help to make the basic plugin better, so it has better paranoia
> >> support without violating GPL licensing.
> >
> > If you like all the features of cdda2wav, you need all of it's code ;-)
>
> I'm not sure what you mean. Are you saying that it is not possible for
> other project to use cdda2wav's paranoia features unless you use all
> of cdda2wav? That seems odd.
Why? If the code was not needed, I could delete it.
> >> 5) Get involved with the cdda2wav project and make it possible for
> >> GStreamer to use its interfaces, which are supposed to work better
> >> than libcdio and do not have GPL legal issues.
> >
> > How does this differ from 1)?
>
> Solution #1 means users don't use GStreamer to interact with CD devices
> and instead have to use the cdda2wav command-line utility or GRIP (which
> is not shipped with Solaris and users have to build/install themselves).
> Most users would likely choose sound-juicer since it has a GUI and is more
> visible in the application menu, and probably not realize the quality is
> not the best.
It is not only missing DAE qualioty but also playability at all.
If you use cdda2wav, you would definitely get better overall usablitity than
what you get from Microsoft. Isn't this an interesting oiption?
> > We could add signals for async commands.
>
> Perhaps this is all that is really needed.
Depends on what you like to do.
> > It will only work in a senseful way if you let cddawav at least extract a
> > track.
> > Note that cdda2wav include all the code to _play_ the data while extracting.
>
> This isn't useful for GStreamer. The GStreamer plugin wants the data and
> passes it to the application to do what it wants with the data. This could
> be playback or it could be ripping or it could be file conversion. The
> GStreamer plugin doesn't really know what the application wants to do with
> the data, so it doesn't make sense for the plugin to play the data directly.
This is why I believe that the interface has been designed the wrong way.
A decent interface should allow delegation of tasks.
You may of course tell cdda2wav to extract a list of sectors and write the data
to stdout. This is suboptimal usage.
> > What do you need except for pause/resume?
>
> The ability to seek. In other words specify that the next sector to play
> could be earlier or later by any amount of time.
...
> > I am not sure whether cdda2wav may work without special privs. It will
> > definitely not be able to do device scanning.
>
> Perhaps we should try to get as much working as we can. If GStreamer
> can't do device scanning, then we may have to rely on the existing code
> for that. At least until a better solution comes along.
I am not sure whether you did understand how to do it best. If you like better
quality than what the Solaris kernel offers via cooked DAE ioctls, you need to
send SCSI commands to the drive (this is what cdda2wav does by default) and
this needs additional privs.
I get the impression this cannot be handled via mail, we should have a phone
call.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
[email protected]
