[vox-tech] update on the audio CD problem

[Micah J. Cowan]

On Fri, Jan 27, 2006 at 07:30:50PM -0500, Peter Jay Salzman wrote:
> On Fri 27 Jan 06,  2:27 PM, Micah J. Cowan <micah at cowan.name> said:
> > On Fri, Jan 27, 2006 at 04:54:14PM -0500, Peter Jay Salzman wrote:
> > > On Fri 27 Jan 06,  1:17 PM, Micah J. Cowan <micah at cowan.name> said:
> > > > On Fri, Jan 27, 2006 at 04:05:23PM -0500, Peter Jay Salzman wrote:
> > > > > On Fri 27 Jan 06, 12:50 PM, Bill Kendrick <nbs at sonic.net> said:
> > > > > > On Fri, Jan 27, 2006 at 05:06:09AM -0500, Peter Jay Salzman wrote:
> > > > > > > Digital extraction is where the cd is read, and the signal gets pumped
> > > > > > > through the ATA port to your speakers.  This is more efficient from the
> > > > > > > CPU's standpoint.
> > > > > > 
> > > > > > Woah, I would think this is way LESS efficient.
> > > > > 
> > > > > No.  The CPU is involved in many read-copy operations when the signal passes
> > > > > through the sound card.
> > > > > 
> > > > > AFAIK, the north and south bridge use DMA during digital extraction.
> > > > 
> > > > Pete, I'm pretty sure that the CPU isn't even /involved/ with analog
> > > > mode. It's analog. There is no read/copy. There's nothing to read/copy.
> > >  
> > > sure there is.
> > > 
> > > data needs to be copied from kernel space to user space.  that _definitely_
> > > requires the CPU.  that's why the whole "zero-copy user-space access" was
> > > such a big deal.
> > 
> > Kernel space? What the heck are you talking about?
> > 
> > There is a direct analog connection from the CD drive to the sound card.
> > It doesn't ever even touch the mother board. The signal sure as hell
> > isn't routed out through the soundcard to the motherboard, and then back
> > into the soundcard. No kernel, user, or any other sort of space is
> > involved.  It's an analog signal, which isn't even representable in
> > kernel or user space unless you convert it to digital, which kind of
> > defeats the purpose.
> 
> 1. read() is performed on a block file device to obtain sound data.
> 2. write() is performed to write the data to the sound char device file.
> 
> it looks like this:
> 
>    read(drive_fd, buffer, size);
>    write(sound_fd, buffer, size);
> 
> the kernel performs these system calls in kernel mode on behalf of the
> application.  the data is read into kernel space, and recopied into
> userspace no fewer than 4 times.

You've /just/ described digital extraction. BTW, DMA is (typically) used
in the read above: that's what you've been referring to. It would be
/impossible/ to refer to the above as analog, since, at the end of it,
you have the data in buffer, which is of course, digital, by its very
nature.

But I'm curious: if the above is "analog", then what does "digital" look
like?

> if you don't understand me, or don't believe me, i'll do the google search
> and post a link that explains this.

I already did. Check a message or two back. Or try it yourself. Here is
the previous link, along with another.

http://www.epanorama.net/documents/pc/cdrom_audio_wire.html
http://www.smart-projects.net/isobuster/help/noframes/hs210.htm

Or, hey, you could look at the source to XMMS's cdaudio plugin, and see
what it does under "Digital Extraction Mode". Here's a summary.

  Digital Extraction Mode:
    dae_play_loop() gets called, which does plenty of read()s and
    write()s. Yes, DMA /may/ be involved (depending on your hdparm
    settings). But it definitely gets copied into user space and back.
  Analog Mode:
    seek() gets called (a local function, poorly named IMO), which does
    a single ioctl() to the CD device file.

> ps- i'm not sure how you can claim that "no kernel, user, or any other space
> is involved" when we're talking about I/O to hardware device files.

That's /exactly/ my point. There is no read/write from any device files,
whatever. There is an ioctl()--to your CD drive device file, and not the
sound card device file. That's it. The actual signal is never, ever in
core memory (or swap). The motherboard (and CPU, and therefore software)
never sees it.

And I can't believe we're still even discussing this. Please give me a
reliable reference, from google or whatever, or let's stop now.

-- 
Micah J. Cowan
micah at cowan.name