Calum:
I spent all day Friday working with Artem from the Tamarack group
and using HAL I was able to test CD playing/ripping functionality
in GNOME. The GNOME CD players don't seem to work well without
HAL. We discovered a few bugs in the HAL code that Artem was
able to fix and we were able to get things working.
Results of the review:
1) Both Totem and Rhythmbox depend on gnome-vfs "cdda:" working
in order to play CD's. We currently do not build gnome-vfs with
cdda, and considering that the gnome-vfs configure.in script
says the following:
[ --enable-cdda Enable cdda module (not recommended)],
Therefore, I am not sure we want to support this. Also gnome-vfs
cdda code depends on the old Linux-specific libparanoia, and not
with the more portable libcdio version of paranoia yet.
So we would need to hack gnome-vfs to work with libcdio if we
wanted this to work. Or hack totem/RhythmBox to use HAL for
playing CD's (probably something the GNOME community will do
eventually anyway).
2) sound-juicer works great as a CD player and CD ripper. I
recommend we get rid of the gnome-media CD player and replace
it with sound juicer.
3) Rhythmbox doesn't really support ripping CD's. It has a button
for ripping CD's, but it just launches sound-juicer. I recommend
we ship Rhythmbox as a program to allow people to manage audio
playlists.
4) I recommend we continue shipping totem for playing videos with
GStreamer codecs (currently only Theora, but will also support
MPEG4, WMV, and encrypted DVD's when Fluendo starts selling
those plugins).
Does this sound reasonable? If so, I'll go ahead and add libcdio,
rhythmbox, and sound-juicer to our builds.
Note that sound-juicer and rhythmbox depend on the nautilus-burn
code to support ripping CD's. Artem and I noticed a few bugs in
the code that need to be fixed to support Solaris:
1) HAL currently returns the /dev/dsk path for the CD device, and
Solaris requires the /dev/rdsk for this to work. Artem is
working with the HAL people to find a solution that will work,
but we may need to patch the nautilus-burn code if the fix
doesn't get into nautilus-burn in time.
2) nautilus-burn tries to read the CD device exclusively with
O_EXCL. This doesn't work on Solaris and needs to probably
be fixed with a patch if the fix doesn't get into nautilus-burn
in time.
Aside from those two fixes, nautilus burn works okay.
Note that for sound-juicer to work, it is necessary for us to build
and ship libcdio as a dependency. With this built, the GStreamer
gstcdio plugin builds, which enables sound-juicer to work.
Since the libcdio library uses flexible arrays which are not yet
supported with Forte, this module will need to be built with the GCC
compiler in /usr/sfw. I believe it would be a lot of work to
refactor the libcdio code to not use flexible arrays. Also, I
hacked this library to *not* build the C++ stubs that it normally
includes. These are provided so C++ programs can link against
libcdio directly if desired, but we can't ship them if we build this
with the GCC compiler since it would break ABI. Not shipping the C++
stubs doesn't break anything for GStreamer or sound-juicer, fyi.
Brian
> I wanted to discuss the spec for the "Sound & Video" section. As you
> highlight, this section is bewildering in its duplicated choices.
> Here's my perspective on what we should be doing and details about
> the programs.
>
> 1) We probably don't need to include Java Media Player in the menu
> anymore. I believe that realplay does everything that JMP can
> do and more.
>
> 2) We probably do not want to ship vu-meter at all. Note that this
> volume meter only works with esd, and aside from desktop sounds
> all GNOME media programs use gstreamer talking directly to the
> sunaudio device rather than esd. So this vumeter isn't really
> very useful.
>
> 3) I think Real Media allows users to play CD's. Therefore, we
> probably don't want gnome-cd in the menu. It isn't a very
> good CD player anyway. If we ever get sound-juicer working
> (we first need to get libparanoia working on Solaris), then
> we could include sound-juicer since it is a good CD ripping
> tool (something Real does not do). So sound-juicer is probably
> OK listed as TBD.
>
> 4) It's annoying that we include Audio Control and "Volume Control".
> We probably need to evaluate these two from a functionality
> and accessibility perspective and figure out which one to
> ship. sdtaudiocontrol uses Java and gnome-volume-control uses
> GTK+ so they both should be accessible.
>
> 5) We probably do want to include totem just because some users
> may want to download Fluendo DVD, MPEG4, WindowsMedia, etc.
> plugins and this tool therefore will allow people to play
> some media types unsupported by Real.
>
> 6) We may want to consider including Jamboree. It is a program
> that lets you manage playlists of audiofiles, much like
> iTunes does. Jamboree does not interact with the CD player,
> but for usrs who have a hard drive full of sound files,
> Jamboree makes it possible to jukebox your audio. I added
> Jamboree to the extra-specs so you can build it and see how
> it works. Let me know if you think this should be added.
> One hassle is that Jamboree uses the gdmb (GNU Database)
> interfaces and we'll probably have to hack Jamboree to use
> Berkely DB instead if we want to ship this. That shouldn't
> be too much work, though.
>
> 7) We should not ship gnome-sound-recorder unless we get around
> to writing a GStreamer 0.10 SunAudio record plugin. There
> currently is no record plugin for Solaris, so you can't
> record anyway. We can add this back (since it is the only
> program that allows you to record audio) if we do this.
>
> So I propose this menu should just have:
>
> Either Audio Control or Volume Control
> CD Database
> Real Player 10
> Sound Juicer (TBD)
> Jamboree (TBD)
> Totem Movie Player
>
> Hope this helps...
>
> Brian
