l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2006 Jan 27 17:10

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] update on the audio CD problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] update on the audio CD problem



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@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@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@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@cowan.name
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!