Re: [vox-tech] update on the audio CD problem
On Fri, Jan 27, 2006 at 07:38:30PM -0500, Peter Jay Salzman wrote:
> > So in this case, the only time the PC's CPU is used is to tell the CD player
> > "Play", then it sits idle. Everything is done by the CDROM drive.
>
> you're not thinking low level enough. system calls are performed by the
> kernel. when a read() is performed, the kernel reads data from a file
> abstraction of a hardware device. the data is in kernel space. the data
> must be recopied into user space.
>
> now the kernel must execute write(). it reads data in user space back into
> kernel space to perform the write() to the sound card's file abstraction.
This is not at all what I understood as "analog extraction." Maybe I
misunderstood the terminology used earlier.
However, what you describe above _sounds_ like what was called "digital"
earlier in the thread, and is therefore far less efficient (CPU-wise) than
what I understood as "analog". Which was the only comment I was making. :^)
(The playback that I'm describing as _more_ efficient, CPU-wise, is where
the CPU simply instructs the CD drive to "play" (probably an ioctl()?), and
that's the end of it. The rest is handled by the CD drive itself, and
even the sound card has little involvement, except as the physical
place where the CD's Line-Out and your speakers are connected.
I think I've even shut down my Linux box, and the CD audio was still playing
right up until the end, long after all of the userspace apps were terminated.)
> not quite. with digital extraction, DMA transfer is used to transfer data
> directly from the ATA device to userland memory. that's the whole point of
> DMA transfer.
Yeah, but again my point was: that's a hell of a lot less efficient than
when you don't have the CPU involved at _all_[*].
And I think like Micah said (or maybe that Y-connector website he ref'd did),
some CD drives have "play" buttons on them. Pressing that button is about
the same as telling KsCD to play the CD. (And this is _different_ from what
I was understanding "digital extraction" -- with or without DMA involvement --
to be.)
Hopefully I'm not being too unclear. I'm kinda distracted by 9-5 work.
[*] Except for sending commands ("Play", "Seek", "Stop", etc.) to the drive.
--
-bill!Tux Paint 2006 wall calendar,
[EMAIL PROTECTED]CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
Micah J. Cowan wrote: 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. No PCM, in any space. Odds are pretty good that you can rig an Analog playback with a /fried/ motherboard, so long as you have some way of getting power to the sound card, and one of those CD drives that has a play button on the front of it. Might take some hacking, and I'm not up to it, but... definitely no digital magic needed. Heck, throw out the _sound card_, and just press play on the front of your CD, with your headphones jacked into the front: it's the same signal. Just to note, my motherboard although I've never gotten this feature to work, has a BIOS toggle to enable the playing of CD's without booting the computer just by keyboard shortcuts (I think my keyboard is incompatible with the feature because of some weird hot key behavior) ASUS A8N-Deluxe (I think) Alex ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri 27 Jan 06, 3:17 PM, Bill Kendrick <[EMAIL PROTECTED]> said: > On Fri, Jan 27, 2006 at 04:05:23PM -0500, Peter Jay Salzman wrote: > > No. The CPU is involved in many read-copy operations when the signal passes > > through the sound card. > > > It was my understanding that in this "analog" CD audio playback scheme, > the data is extracted by the CD Drive itself, converted to analog with the > drive's own built-in DAC (just like what's in a CD Walkman or a stereo), > and then wired directly to the sound card's "Line In" pins, and passed > along to the speakers. (Mixed on the card in an analog state.) > > So in this case, the only time the PC's CPU is used is to tell the CD player > "Play", then it sits idle. Everything is done by the CDROM drive. you're not thinking low level enough. system calls are performed by the kernel. when a read() is performed, the kernel reads data from a file abstraction of a hardware device. the data is in kernel space. the data must be recopied into user space. now the kernel must execute write(). it reads data in user space back into kernel space to perform the write() to the sound card's file abstraction. a kernel always executes system calls in kernel mode. > In the "digital extraction" mode (which Norm has to do -- perhaps because > that little wire connecting the CD drive to the soundcard is missing), > the CPU is used to actually take the data off the CD and send it to the > sound card (via the motherboard, rather than that little wire). not quite. with digital extraction, DMA transfer is used to transfer data directly from the ATA device to userland memory. that's the whole point of DMA transfer. pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri 27 Jan 06, 2:27 PM, Micah J. Cowan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri, Jan 27, 2006 at 04:05:23PM -0500, Peter Jay Salzman wrote: > No. The CPU is involved in many read-copy operations when the signal passes > through the sound card. It was my understanding that in this "analog" CD audio playback scheme, the data is extracted by the CD Drive itself, converted to analog with the drive's own built-in DAC (just like what's in a CD Walkman or a stereo), and then wired directly to the sound card's "Line In" pins, and passed along to the speakers. (Mixed on the card in an analog state.) So in this case, the only time the PC's CPU is used is to tell the CD player "Play", then it sits idle. Everything is done by the CDROM drive. (This really _must_ be the case, since the earliest CDROMs could play music just fine, even on 486s.) In the "digital extraction" mode (which Norm has to do -- perhaps because that little wire connecting the CD drive to the soundcard is missing), the CPU is used to actually take the data off the CD and send it to the sound card (via the motherboard, rather than that little wire). I'm not very knowledgable about audio formats used by either CD _or_ soundcards, so it could just be a matter of 1:1 copying the data. (In the amaroK example I gave, I think it may have been ripping and encoding to MP3, and then _decoding_ the MP3 to play it, which is absolutely retarded. But, that's just a guess... after trying it once and asking in #amarok on IRC, I learned it was just something you didn't want to try yet, and to stick with KsCD.) -- -bill!Tux Paint 2006 wall calendar, [EMAIL PROTECTED]CDROM, bumper sticker & apparel http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. No PCM, in any space. Odds are pretty good that you can rig an Analog playback with a /fried/ motherboard, so long as you have some way of getting power to the sound card, and one of those CD drives that has a play button on the front of it. Might take some hacking, and I'm not up to it, but... definitely no digital magic needed. Heck, throw out the _sound card_, and just press play on the front of your CD, with your headphones jacked into the front: it's the same signal. The only thing "digital extraction" mode is good for is that many times that physical connection between between CD drive and soundcard has not been made: or, you might have more than one CD drive, and the CD happens to be in the one without the physical connection. But digital extraction, DMA access or not, certainly involves /many/ read/copy actions on the part of the CPU, which is why it is intrinsically more expensive than analog playback mode (which involves none). Well, also there's the fact that the CD drive's built-in DAC (which drives the conversion to the analog signal which gets sent to the sound card) may not be as great as the software you have in your computer. Which isn't a small thing. BTW, see http://www.epanorama.net/documents/pc/cdrom_audio_wire.html for instructions on building a Y-connector for CD audio cables, which solves the problem of multiple CD drives... -- Micah J. Cowan [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri 27 Jan 06, 1:17 PM, Micah J. Cowan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri, Jan 27, 2006 at 04:05:23PM -0500, Peter Jay Salzman wrote: > On Fri 27 Jan 06, 12:50 PM, Bill Kendrick <[EMAIL PROTECTED]> 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. -- Micah J. Cowan [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri 27 Jan 06, 12:50 PM, Bill Kendrick <[EMAIL PROTECTED]> said: > On Fri, Jan 27, 2006 at 05:06:09AM -0500, Peter Jay Salzman wrote: > > Analog extraction is where the the cd is read, the signal goes through a > > cable between the cd player and sound card, which gets pumped through your > > speakers. Point being, a physical connection between the cd drive and sound > > card is required. > > > > 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 ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri, Jan 27, 2006 at 12:37:31PM -0800, Bob Scofield wrote: > Thanks for the step by step directions. I had been using KSCD for music > CD's. > But KSCD's volume is poor. XMMS really projects nice volume. I had been > using XMMS for radio, but not CD's. I think the issue here is that XMMS, if it's doing the "digital extraction" method as Pete recently described, is taking the digital CD data and pumping it to the sound card. In that case, it's probably being output as "PCM" sound. KsCD is simply sending a command to your CD player: "Play", and the audio is passed between the CD drive and your sound card (inside the PC via a little cable). It's being used as an input (like a Mic or Line-In would be). In that case, it's probably wise to check both the "Master" output volume, AND the "CD" input volume, In KMix in KDE, it's literally "CD" in the "Input" tab. I'd be curious to see how CPU usage is affected when one uses XMMS 'digital' vs. XMMS 'analog' or a tool like "cdplay" or KsCD... Anyone feel like running "top" and listening to some tunes? :) -- -bill!Tux Paint 2006 wall calendar, [EMAIL PROTECTED]CDROM, bumper sticker & apparel http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Fri, Jan 27, 2006 at 05:06:09AM -0500, Peter Jay Salzman wrote:
> Analog extraction is where the the cd is read, the signal goes through a
> cable between the cd player and sound card, which gets pumped through your
> speakers. Point being, a physical connection between the cd drive and sound
> card is required.
>
> 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. One of the big problems
with amaroK (at least a while back) was that it did not have any facility
for directly playing audio CDs. ("Analog extraction", as you called it.)
Whereas one can simply hit "Play" in something like KsCD or XMMS and the
CD player starts doing all the work (and the sound card simply passes the
CD's sound out to your sound card), when you tried to play an audio CD
with amaroK, it would have to read the actual digital data, turn it into
sound, and then have your sound card play it.
One is more like a CD Walkman (where the CD drive itself has a DAC,
and then it's just sound cabling inside that gets the sound to your speakers),
the other is more like ripping a CD _AND_ playing back the audio data
(where the CD drive's DAC isn't being used, but your main CPU and your sound
card's logic chips are being utilized).
> At least that's my understanding.
Well... I guess I should say 'ditto' for _my_ understanding, too. :^)
(I just know from amaroK that it was not recommended, and that they were
working on adding the capability to just have amaroK control the CD in
the "walkman" fashion, like KsCD, the command-line "cdplay", etc. do it).
--
-bill!Tux Paint 2006 wall calendar,
[EMAIL PROTECTED]CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Thursday 26 January 2006 11:51 pm, Norm Matloff wrote: > Many thanks to Micah and Bill for their response to my query on the audio > CD problem. Here is the result. > > > > I was able to get my machine to work by taking a combination of Micah's > and Bill's advice, PLUS something I found on the Web. Here is what I > did: > Thanks for the step by step directions. I had been using KSCD for music CD's. But KSCD's volume is poor. XMMS really projects nice volume. I had been using XMMS for radio, but not CD's. Bob ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Re: vox-tech Digest, Vol 20, Issue 28
> Date: Fri, 27 Jan 2006 05:06:09 -0500 > From: [EMAIL PROTECTED] (Peter Jay Salzman) > Subject: Re: [vox-tech] update on the audio CD problem > To: lugod's technical discussion forum > > harder, since the symptoms there had been worse. But it turned out to > > be a very simple problem in that case: The file permissions on /dev/hdc > > were not set correctly. > My permissions are: > >brw-rw 1 root cdrom 22, 0 2006-01-18 04:28 /dev/hdc It was the same on my daughter's machine. But the non-root account she set up for herself wasn't in that group. I suppose the settings were a conscious decision on the part of those who set up the distro. Wouldn't want the riffraff playing music, ya know. :-) Norm ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Thu, Jan 26, 2006 at 11:51:08PM -0800, Norm Matloff wrote: > I then turned to my daughter's machine. I had thought this one would be > harder, since the symptoms there had been worse. But it turned out to > be a very simple problem in that case: The file permissions on /dev/hdc > were not set correctly. :-) I've noticed that Fedora resets permissions on these things from time to time. Make sure you did it the "approved" way (which, unfortunately, I don't remember). But just manually running chmod is not going to work. You'll have to google for this one, I'm afraid (unless someone onlist remembers how you're supposed to do it). -- Micah J. Cowan [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] update on the audio CD problem
On Thu 26 Jan 06, 11:51 PM, Norm Matloff <[EMAIL PROTECTED]> said: ... > 1. I downloaded and installed a plugin for XMMS, > >xmms-cdread-0.14a-4mdk.i586.rpm > > (It did not seem to matter that that was a Mandrake RPM while my > machine runs Fedora Core 4.) That's pretty common. At least it used to be way back when. ... > Mind you, I do not fully understand the details of why these steps were > necessary, but they all did seem to indeed be necessary. (I tried > experimenting by omitting one step or another, and it didn't work.) It's my understanding that there are two ways of playing a CD in a computer: 1. analog extraction 2. digital extraction Analog extraction is where the the cd is read, the signal goes through a cable between the cd player and sound card, which gets pumped through your speakers. Point being, a physical connection between the cd drive and sound card is required. 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. At least that's my understanding. ... > harder, since the symptoms there had been worse. But it turned out to > be a very simple problem in that case: The file permissions on /dev/hdc > were not set correctly. My permissions are: brw-rw 1 root cdrom 22, 0 2006-01-18 04:28 /dev/hdc Rather than play with permissions, you may want to play with groups: 1. chmod 660 /dev/hdc 2. chgrp cdrom /dev/hdc 3. add the usernames you want to give cd access to /etc/groups Not crucial. Just an alternative. Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
