[vox-tech] update on the audio CD problem

Peter Jay Salzman p at dirac.org
Fri Jan 27 16:30:50 PST 2006


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.

additionally, there are user/kernel context switches, and that also takes up
effort and time.

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

with digital audio extraction, DMA can be used to copy data directly from
the drive into userland memory.  this is the whole point of DMA transer.

pete

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.  doesn't
that seem a bit silly to you?  after all, the kernel's main function is to
interface with hardware and manage memory.


More information about the vox-tech mailing list