I am attempting to back up my audio cds (time to throw them out) to the cloud. I have a two cd-roms. I am using cdrdao to read the audio from, and vlc to listen to the cd audio on the other drive.

However, I am finding that while cdrdao is reading the one audio cd, that it seems to be affecting the performance of listening to the other cd. (lots of lag with both vlc and mplayer)

To take it one step further, even when I use cdemu, to emulate the ripped audio, that it experiences the same audio lag when the hardware cd-rom is being read from. When it is not being read from, then the audio is smooth.

It appears to be a case of buffer exhaustion, however I am confused to how this can be the case since it seems as if they should be separate entities.

I have two optical drives that I use to rip audio books for my wife and I've noticed the same thing. I use icedax for the ripping and have developed scripts to automate the process with one drive ripping the odd numbered cds and the other the even numbered cds. When inserting or ejecting a cd in one drive while the other is ripping, the one running will grind to almost a halt and doesn't pick up again to the newly inserted cd spins up and starts doing its thing.

We're using different tools, icedax vs cdrdao, and getting similar results with two optical drives running simultaneously so I assume it's something in the way the kernel handles multiple running optical drives. My guess is no one is particularly interested in working on that part of kernel since optical drives are on the way out and most people don't have one optical drive, much less two. Also, things work but just not as optimally as they could. If someone knows a way around this problem, I would welcome a solution as well.

Are your devices connected via SATA? Then you might try an external USB-drive...

Mine are sata connected. I have a powered sata to usb adapter and an old optical drive and will give it a try when I have time.

Maybe you can borrow a USB-device from a friend...

Using a usb connected drive makes no difference. Ejecting one drive makes the other running drive slow to almost a halt and inserting a new disk slows the other running drive until the new one spins up. Tested by using icedax to rip audio cds, first on one drive then on the second while the first is running.

That's -- funny. USB and SATA should be from very different kernel modules. Did you try a "ps ax" in a console and look for any suspect processes which might block the devices? Or any job using up a lot of CPU time or abusing the I/O-buffers...