gxine-0.4.3 plays audio CDs at max spin rate. This makes infernal whiring sound that is almost as loud as the music I wanted to listen to. This makes it unusable in reality. cdplay runs the same hardware at , I guess 2x and the drive is inaudible. I mark this a major because it is unusable for audio CDs. Reproducible: Always Steps to Reproduce: 1.gxine 2.ctrl-C 3.cdplay --device=/dev/cdroms/cdrom1 -c Ahhh! Expected Results: software controls drive to run at an appropriate speed for audio.
gxine uses xine-lib for decoding/playing. Please try to reproduce with xine-ui to see if the problem is gxine specific or with xine-lib. Also please note that there's a xine setting which allows you to select to which speed the drive should be slowed down, which defaults to 4x. If the problem is not gxine specific but with xine-lib, please consider reporting upstream because in my system (and in the previous one) it works quite fine out of the box, and also if the cdrom was going to be at maximium speed, the noise it's not so high and that's probably something related to your setup.
Thx for your comments. I am sure that there is means somewhere to control the speed but there is nothing in gxine interface and gxine is clearly running the CD at an inappropriate speed. >>the noise it's not so high /// well that is completely subjective, it's too noisey at high speed , I should not be able to hear the drive whilst playing music. It is a bug. I dont have time to debug every bit of faulty software in portage, that's what maintainers are for and why we file bug reports. There's a fault , I do my part in flagging the problem. >>because in my system it works quite fine out of the box Are you saying that you can play a CD in gxine and it runs at 4x?? Version numbers pls. Thx again.
I'm not using gxine right now, I've tried with kaffeine and xine-ui (which uses the same backend and has the configuration option). And as I said, also if the cd is spinning at highest speed in my reader, I can't hear it anyway. That's dependent on the hardware you have. If you still don't want to test that with xine-ui, I'll ask you to report that upstream, because it's not a generic bug with a software in portage caused by a combination of softwares in portage, but more probably something with the code of the software itself which is related to your specific hardware.
I have emerged xine-ui but I am having a few udev probs and cant even see the drive at the mo. I will happily dump gxine if I find a better player, it's too windozey for my taste. >>And as I said, also if the cd is spinning at highest speed in my reader, I can't hear it anyway. So you have a better drive , that does not mean that spinning full speed to read an audio CD is not a bug. >>I'm not using gxine right now >> it's not a generic bug with a software in portage caused by a combination of softwares in portage How do you conclude that ? You dont have the software, you have not tested it, I have. I thought the whole point of bugs.gentoo.org was to check if reported bugs were gentoo related (which apparently you have not since you dont have the s/w) and to transmit the bugs upstream if necc. At least last time I read that was the way it worked, not user debug s/w : user bug upstream. Otherwise everyone become a dev for thier own personal distro. and spends thier life debugging it.
As I said, I *can't* test it because I can't state the speed of my reader from the noise, so I'm *not* able to test if gxine is the problem in itself. That's why I asked you to test with xine-ui. Both xine-ui and gxine uses the same backend library, if one works and the other no, the problem is in the frontend. I can't know if one does and one don't because, as I have repeated, I *can't* test it with my reader. If the problem is with gxine, you probably should report that to gxine authors, as it's a missing feature; if the problem is with xine-lib, it could be with portage's libraries, in which case I'll check for incompatibility. This is dued by the way gxine work: it just instructs xine-lib to do what you need.. if the same command works in xine-ui but not in gxine, the responsible is gxine without other interactions with portage's libraries.
OK I have been able to test with xine-ui now that I have my udevs sorted out. If I config xine to use /dev/dvd -> /dev/sr1 = ide-scsi as audio player I can hear the speed down is working, however if I use /dev/cdrom -> /dev/sr0 = true scsi drive it runs at full speed. I can compare to using xcdroast to read the disk at 32x. I have yet to see an optical drive that makes no more noise at full speed as at 4x so this is fairly simple to verify even if it is not possible say exactly how many rpm the disc is running at. Reading a scratched disc in sr0 with xcdroast will slow down and speed up the drive as needed in a consistant and clearly audible manner. So the bug is not gxine specific and does not come from the kernel support for the scsi card either since it works with other s/w. It may be specific to the interface with a true scsi device since the atapi DVD writer running under ide-scsi does not seem to display this problem.
title mod.
Please report upstream, that seems not to be a Gentoo-specific problem. If they'll have a patch for this, please reopen.
