[svlug] music CDs and USB audio
florin at sgi.com
Thu Jan 2 12:30:54 PST 2003
On Thu, 2003-01-02 at 01:00, Ira Abramov wrote:
> under M$, the media player extracts audio at roughly 1X and spools it as
> a regular "wave" file to the USB speakers. in Linux all I could find are
> players that send play commands to the IDE drive. any hints about How
> can one use Audio CDs on a system with USB speakers?
To put it in different words, what you want is to extract the audio
tracks from the CD, and send them to a PCM player.
The first and best method would be to find a player that actually does
this (extract the tracks and play them as any other PCM stream) by
default. I'm not aware of any, but that doesn't mean there is no such
Second, you could try to put together everything in two steps:
- extract the PCM stream with cdparanoia
- pipe it through stdout --> stdin to a player which is able to play a
PCM stream from standard input (usually a command-line WAV player should
be able to do that)
I'm sure it's much easier to find such a player. Then you could write a
shell script to combine cdparanoia with it. Example:
cdparanoia -qep 1- - | fooplayer
Now, i'm not sure just how an USB speaker works. Can you play MP3s with
XMMS to it? Or you "see" it like a drive, or a device, or what?
If you see it as a device, you could redirect cdparanoia to it, and
tweak the parameters if the speaker expects a WAV header, etc.
Also see at the end.
On typical hardware, cdparanoia is usually able to extract the audio
tracks faster than real-time. If not, just use some CLI switches and
disable some of its most pedantic checks (experiment with -Z or -Y).
There's yet another answer to your question, but i'll write that below,
after i'll comment your other issue.
> while writing the question I finaly bumped into these two projects:
> which supplanted this: http://software.senko.net/audiofs/
> any words pro or con, or more pointers?
Yes, there are many such implementations. Some of them are quite old,
and possibly are not maintained anymore.
Their usual advantage is convenience and (sometimes) speed. Pop in your
audio CD, mount it, and there ya go, you can see the songs as WAVs or
any other 16 bit PCM files (the difference between the CD audio track
and WAV is just the header), so that you can use them in any application
without requiring it to understand the audio CD format.
Their usual disadvantage is lack of reliability. That's because most of
them simply dump the bytes onto whatever application wants them, and
there are no provisions for error recovery. If there's a scratch on the
CD, that's just too bad, buddy! :-P
So, it depends on what are your needs. For ripping audio CDs to MP3 or
Ogg Vorbis, cdparanoia is _always_ recommended. For quick tests, the
audio CD "filesystems" might be more appropriate.
The nice thing about cdparanoia is that it provides a library to its
core functions, so that other applications can have the same
capabilities of reading audio CDs reliably (error checking and recovery,
persistent re-reads, etc.). Read the documentation, it's quite
So, if you find an audio player that's linked to cdparanoia-devel,
there's a chance it will do what you want: "rip" the track from the CD,
"pipe" it (not necessarily via std[in|out]) internally to some
integrated PCM player (which possibly is the simplest type of multimedia
player, because it doesn't need much processing) which in turn plays it
to the audio driver.
If you feel brave, you can experiment with dumping the PCM stream from
cdparanoia directly into the appropriate devices - things like
/dev/audio and such. Like:
cdparanoia -qep 1- - > /dev/audio* #(not sure about which device)
If you do the right thing, it will simply work; sometimes you need to
tweak the stream a little bit by inserting sox in the pipe, to fix
things like endianness, number of bytes per sample and other such
annoyances, depending on hardware, architecture, etc., or even to
provide volume control, tone filters, echo effects...
If you want to go really nuts, you could pipe cdparanoia into netcat :-)
possibly with inserting gzip and/or sox in the chain, then do the
reverse process on a different machine. :-) Oh, the possibilities!
But it's been a _long_ time since i played with these things, so have a
grain of salt handy.
"And the man in the rain picked up his bag of secrets, and journeyed up
the mountainside, far above the clouds, and nothing was ever heard from
him again, except for the sound of Tubular Bells." - Mike Oldfield
More information about the svlug