[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sound on iMac



>>> Jonathan Riddell <jr050@jriddell.org> 27-Feb-01 9:59:28 PM >>>

>If I do insmod dmasound, that lets me do stuff like 
>cat english.au > /dev/audio 
>but I can't play CDs for example.

The reason you can't play audio CDs is probably because you're using
CD player software that doesn't handle the iMac's digital audio
system.

AFAIK there isn't a gui cd player that does this.

Instead you can use use cdda2wav as a sort of pipe to stream data off
the CD and into the audio device.

The following command plays tracks 2 to 12 of a CD in the iMac rom
bay:

  cdda2wav -t 2+12 -D /dev/cdrom -N -e -d0 -I cooked_ioctl -q &


Andrew Arthur has written a script to make using cdda2wav a bit
easier. It pulls in cddb and aumix to make track selection and volume
setting easier. His code is the source of the command above.

Andrew's script has some problems though so I can't unconditionally
recommend it. If you want it go over to linuxppc.org and do a search
for:  icd

I'm trying to work out how Andrew's script could be improved but
doing this in a user independant way isn't easy. The current state of
the player needs to be maintained, where do you maintain that state if
not in .files? 

If the user interface is to allow "next" and "prev" operations then
the player script has to play tracks one by one... that means that the
player script has to be executed when a track finishes.

Andrew's code does it by having the icd script hang around in
memory... but that brings it's own problems.


I've been thinking about having a script that wraps the call to
cdda2wav. When cdda2wav completes the script can then play the next
track if that's what's needed.

To support next and prev I thought that perhaps writing to the
inputstream of the wrapper script and sending it a signal might be
enough...

It would be very much easier if one could accept that the player
could only be interacted with by one user at a time, ie: once a CD is
playing only the user who started it can stop it. This isn't ideal but
I guess it's a fiar enough simplification.

If anyone has any other ideas I'd love to hear them.


Nic Ferrier



Reply to: