Changing the interest list to desktop-discuss, which is more appropriate
than opensolaris-discuss. Also making the subject a bit more clear about
what the discussion is about.
To summarize the discussion so far, J?rg, who is the author of cdda2wav
has explained in great detail why cdda2wav is superior for both CD playback
and ripping than the other tools on Solaris (e.g. sound-juicer and totem
which use GStreamer).
cdda2wav is a command line tool, and Sun currently ships no GUI that works
with it, so playback and ripping is done via running commands. The GStreamer
based programs access audio CD data via the GStreamer CDDA plugin that was
written here at Sun by Artem and me.
This GStreamer plugin has no error correction (e.g. libcdparanoia), so
skips and artifacts can creep into your playback and riped files. Also,
many CD drives are unable to read some CD's without using cdda2wav because
cdda2wav uses superior SCSI ioctls. These ioctls require privilege, though,
which are not available to programs that use GStreamer.
So, how could we fix this:
1) The cdda2wav tool is written with the assumption that the user either
wants to send the data to the sound card or to a file in WAV format.
However, the GStreamer framework provides the audio stream to the
running media program so you could do fancy things like a DJ
appliation that would mix the audio of multiple audio CD's, apply
audio effects to the CD output (such as echo or EQ), or rip the audio
to formats other than WAV.
It probably doesn't make sense for cdda2wav to try to implement all
possible ways that a program might want to deal with CD audio, so
perhaps the interfaces that cdda2wav uses could be made available by
other programs, such as GStreamer. This could be done either by
giving privilege to all programs that use the GStreamer CDDA plugin
or perhaps creating a service that deals with the tasks that require
privilege and both GStreamer and cdda2wav could use that service.
2) We could write a new CD player/ripping tool that worked with cdda2wav,
GRIP is an existing exmaple.
Currently cdda2wav doesn't support the ability to control the output
stream to do effects like pausing, or rewinding/fastforwarding through
a song. Perhaps some users wouldn't like using a player that didn't
allow such expected features. However, it probably wouldn't be too
hard to enhance cdda2wav to support things like this.
The GRIP application uses cdda2wav for ripping, but uses GStreamer
for audio playback. We don't currently ship GRIP with Nevada, and
a player that rips well but can't play CD's well isn't really a
great solution.
We could also, I suppose, enhance sound-juicer and rhythmbox to use
(or be configured to use) cdda2wav instead of GStreamer.
This provides a reasonable CD ripping/playback solution for Solaris,
but doesn't solve the quality issues if you want to use any program
that are not cdda2wav based.
3) The libcdio interface works with GStreamer and is of higher quality
than the CDDA plugin we ship with Solaris. Unfortunately libcdio
is GPL'ed and cannot be linked into LGPL'ed GStreamer. Also
libcdio seems to have other issues, including being of lower quality
than cdda2wav, according to J?rg. But users who wanted to use it
could build it from spec-files-extra, then rebuild the
SUNWgnome-media packages so that the cdiocddasrc plugin gets built.
Then configure GStreamer to use it instead of the default and more
primitive cddawav CDDA plugin. This would allow GStreamer based tools
like sound-juicer and rhythmbox to have higher quality CD playback and
ripping until something better (hopefully based on cdda2wav) comes
available.
I'm not sure how important CD playback/ripping quality is on Solaris,
or if Solaris is "good enough" even with these problems. Obviously
there are opportunities to make things better, so if there are people
in the community interested in working in this area, then here is an
example of an area that could use work. But, for now, people who
really need quality CD ripping and playback can use cdda2wav as is.
J?rg has an expressed an interest in possibly working with the JDS team
to provide the needed interfaces to make cdda2wav functionality
available to GStreamer (though it may be lower optimal than calling
cdda2wav directly). Assuming this work can be done, then I can't
imagine it would be much work to write a cdda2wav-based plugin for
GStreamer. You'll notice that the existing cdda2wav plugin is only
700 lines of code, so it doesn't really do that much.
Note in the below discussion, J?rg points out that most CD's can only
play 60% of the CD's out there. He lists a few drives (that all seem
out of production) that do work better on Solaris. So, if you are
looking for optimal CD performance on Solaris, getting your hands on
one of these better drives might be something to consider.
In the below email, J?rg says:
> I get the impression this cannot be handled via mail, we should have a phone
> call.
Sure, I do think it would be useful to have a call. Are you volunteering
to do the scheduling? I don't think anybody aside from the cdda2wav and
JDS multimedia teams would need to be involved. Jerry Tan, who is cc:ed
is the right person to contact in order to schedule a phone meeting. Note
most of the JDS multimedia engineers are in Beijing, and I am in Chicago,
so hopefully we could find a time that would work best for everyone? We
could also have more than one phone call if time differences makes things
complicated to schedule.
Brian
For those who want to read some of the opensolaris-discuss thread that let
to this email, read on...
>> Brian Cameron said:
> J?rg Schilling said:
>
>> Well, lets start up the conversation again. 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
