Re: [Kreatecd-devel] KreateCD on Sparc/Solaris

[Alexander F. <Ale...@gm...>]

On 18 Mar 2001 16:23:06 +0000, Keith Refson wrote:
> Dear Developers,
> 
> I'm looking for a decend GUI ripper/burner for KDE 2.1 under Solaris 8 on
> a Sun sparc system.  KreateCD seems to be one of the most popular of
> the CD burning tools, so I thought I'd try here, and ask for some
> assistance. Obviously KreateCD has not been ported to Solaris
> before, as an attempt to compile it shows. However it looks quite
> promising, and I'm prepared to contribute some development and testing
> work, if the main developers can assist me with advice on the
> structure, assumptions etc.

I'm very interested to port KreateCD to other OSes. I couldn't answer
earlier because I'll have a written exam tomorrow. After that I have
more time to assist you. I'll have a look at your patch ASAP.

> 
> Firstly, I'll contribute some changes which allows it to compile, and to
> start up.  I'm attaching as a diff, though I doubt this will be the
> final form.
> 
> 1. Busscanner.cpp:    Solaris does not have the "unsetenv(3)" call.  I
>    just used "putenv" to change the env variable to a null string, but
>    I don't know if that achieves the objective or not.  
> 

We could check if we still need that. Some versions of cdrecord didn't
report all scsi devices if the environment is set to use a certain
device. This might be fixed in current versions - will check that soon.

> 2. AudioFileOp.cpp.  Solaris does not have and "soundcard.h" file, and
>    the audio system is quite different.  However this module does not
>    appear to actually require definitions from this header, and it
>    compiled without it.
> 

Hmm. Seems like we can safely remove that. I reorganized and splitted
the source files some time ago and it seems like there is an unused
include left.

> 3. AudioFileConvert.cpp.  Again the issue is "soundcard.h" but in this
>    case the module does require this.  I'm not sure where this module
>    fits in and what it does.  If someone will explain this to me I can
>    try to interface it with the Solaris audio system.  I got the
>    module to compile by commenting out the functionality as a test.
> 

This is used to setup the /dev/dsp device file for 44100 Hz, stereo
16bit sound data. I use the same code for converting and playing sound.

> 
> Of course this does not address most of the real portability issues to
> solaris, which are:
> 
> 1. Support program issues.  We are not in bad shape here.  All the
>    CDR-tools stuff works perfectly under Solaris (of course!).
>    However to my knowledge cdparanoia does not work under Solaris.
>    mpg123 is fine.

Cdparanoia will be ported to other OSes some time. (they don't work on
paranoia at the moment because they want to finish the first stable
version of the ogg vorbis codec ). We can use cdda2wav, which is
available under Solariso. cdda2wav should be selected if there is no
cdparanoia available. Otherwise cdparanoia is used. 

> 
> 2. Endian-ness and alignment (on sparc anyway).  I have found some
>    mp3-handling code to have endian assumptions, and to assume
>    intel-like word alignment (ie anything goes).  However I have been
>    able to at least add an mp3 file to the track list, and kreatecd
>    apparently gets the length right.  

Hmm. Endian-ness (on harddisk) should be handled by the
"wrapper-methods". They should return the same result for BE and LE. I
don't have much experiences with endian-ness yet so I cannot tell if
there are any bugs in it. But if you get a correct length of your mp3
files it looks very promising.

> 
>    When ripping CDs or burning from raw CD audio image tracks, the
>    endianness assumptions may differ.  cdda2wav and cdrecord can do
>    either, but perhams an explicit flag is required.

The correct behaviour would be that all helper apps and all converters
write an image file suitable for cdrecord. The bytes are already swapped
for the CD-R.

> 3. Device names, and handling of data CDs.  I don't know whether this

>    is an issue or not.  Solaris' volume daemon mounts data CDs under a
>    subdirectory of /cdrom/cdrom0 and makes the raw device available under
>    /vol/dev/aliases/cdrom0 (and higher numbers for multiple drives).
>    This "alias" device only exists while a CD-ROM is actually
>    inserted.  Audio device names are different too (/dev/audio) -- see
>    4.
> 

The current method of data ripping is not very portable. Are there any
helper apps we can use to rip data ? An ideal helper app would base on
libscg - which is available under most OSes. It would be even better if
that helper app could read raw data and subcodes if required. (for
further extensions) 

> 4. Solaris has a completely different audio system and interface.  In
>    fact not much of KDE 2 audio works under Solaris :(.  However for
>    direct use it's quite simple to use, so if someone points me to what
>    is needed, I can try writing some code.  
> 
>    Ironically the (gnome) enlightenment sound daemon works fine!
>    Closed and proprietary solutions such as OSS are of no use either.
> 

I don't have any information about the Solaris audio system - so I can
only describe how OSS works here (if you don't know already). Where can
I get information about the soud system of Solaris?

> 5.  It would be nice to add support for Solaris' native ".au" sound
>     format.  Cdrecord handles this just fine.
> 

Is there any way to detect that audio format? 
The current code tries to convert everything to cdr format and doesn't
rely on cdrecord to do this job. We would have to extend the conversion
code for au and everything would work fine.

 
> So if anyone feels willing to hold my hand and walk me through where
> changes might be needed in any of the above areas I'd be grateful.
> 
> Finally a report on what does seem to work and what doesn't.  
> 
> 1. I can drag and drop mp3 and wav tracks into the track list, and the
>    length is extracted correctly.
> 

There can't be any major endian problems if that works.

> 2. Double-clicking to see the "properties" works fine for mp3 files.
>    However wav files produce the message "Audio track\nWARNING:
>    unknown format!" in the properties display.  The console log does
>    show that it is assigned a mime type of "audio/x-wav".
> 

Hmm. I will have to check that after exam. Might be an endian problem :)

> 3. Further clicking the "options" button again works for mp3 but not
>    for wav.

Wav cannot work because it is not detected correctly.

> 
> 4. Under "settings" the SCSI bus scan correctly detects and identifies
>    my CD-R device. 
> 

No surprise - as it relies on cdrecord. 

> 5. Attempting a simulated burn from mp3s seems to invoke cdrecord correctly,
>    and apparently succeeds.  I haven't yet tried a real burn.
> 

You don't have a CD-RW, do you? I hope I can afford one in a few months.
It would be much easier to test kreatecd if we all had a CD-RW. 

If you have a CD-RW please burn a CDDA to test the endian. 

> 6. Tools-> copy correctly gets the tracks and lengths from an audio or
>    CD-Extra.

It relies on cdrecord and cdda2wav - it should be portable without any
problems.

> 
> 6. Ripping does not work.  Clicking on the track in the main window to
>    get the "Properties" panel, and then the "options" button invokes
>    the "Extracting" panel and apparently runs cdda2wav successfully.
>    Indeed I can see the temporary file growing.  However the progress
>    bar stays at 0% although cdda2wav updates its running percentage
>    counter.
> 

Sounds like kreatecd cannot parse the stdout/stderr lines of cdda2wav.

>    Finally, on completion of the track read, there is a popup "Unable
>    to read audio track!", and on "OK", another error panel "Cannot
>    read source track!".  This *may* just have something to do with the
>    fact that cdda2wav ignores the requested  filename extension of
>    ".cdt" and puts the output file in ".cdr" instead!  This happens
>    with both cdda2wav 1.9 and 1.10a16!

The cdda2wav ripping code might be completely broken on Linux too. If
cdparanoia is available it will be used for audio ripping. I did only
some test rips a very long time ago. I didn't touch the code since then.
It problably does work with an older version. We should check cdda2wav
ripping on Linux first. If it works here we know it is a porting
problem. 

Almost for sure we will have to fix that filename problem.

> 
> So here's hoping that some of the developers are keen to assist me
> with a Solaris port.
> 


Alexander Feigl