Version: 1.4.5 (using KDE KDE 3.5.5) Installed from: Debian testing/unstable Packages OS: Linux There's no way to select output to /dev/dsp1 using the Xine engine + OSS. Even if I edit the xine-engine's config file in .kde/share/apps/amarok/ to include /dev/dsp1 in the list of options, it still won't accept it. On my machine, /dev/dsp is the internal mono laptop speaker, whereas dsp1 is the hi-fi via a USB soundcard. This soundcard works perfectly using direct output (/usr/bin/play). I tried to access it with alsa as hw:1, which works for a few minutes, but then always crashes. At the moment, I'm using the workaround of amarok -> arts -> oss -> /dev/dsp1 (which is extremely ugly, and pushes the CPU-load very high) I think this is a simple bug to fix, since other players (eg beep/xmms) work just fine, and list all the available soundcards. Perhaps the easiest solution is either: 1)List all devices matching /dev/dsp* or /dev/sound/dsp* 2)Allow the user to type in the device name, if it isn't one of the standard options.
Workaround: there is a really easy fix: cd /dev; mkdir sound; ln -s dsp ../dsp1 And then Amarok can output to /dev/sound/dsp in blissful ignorance :-) Incidentally, the Arts engine is unusable, since it can't cope with the join between 2 tracks - it "stutters" badly. (amarok is the only significant process running, but the CPU is only 600MHz).
we use phonon now, should fix this
Don't forget: there are still quite a lot of users of kde 3.x, who don't have the system resources to run pulseaudio. So please do fix this.
Richard we know that but we simply don't have the time and resources for it. Sorry.
Yes... but this is a literally 5-second fix. The problem is as simple as adding an extra entry to a drop down box. At the moment, if you go through the menu and choose xine-engine and oss output, you get a drop down menu for the device. This only gives two options: /dev/dsp and /dev/sound/dsp. Presumably these are defined in some header file somewhere, so adding options for /dev/dsp1 through 8 would be really easy! (Ideally, of course, it should be a free-text field, or better auto-detection, but that would take more than a couple of minutes to fix, whereas that hack would be perfectly adequate)
Ok. Can you provide a patch? Attach it here and reopen the bug so devs can have a look at it. Thank you.
I looked through the source, and this isn't actually amarok's fault. Amarok gets an array of possible options directly from the Xine engine. Furthermore, gxine suffers from exactly the same bug. So I'm filing a Xine bug report here: http://bugs.xine-project.org/show_bug.cgi?id=132 I agree that this bug is invalid for Amarok - sorry to have wasted your time. Richard