M-.-n wrote: > Joern Nettingsmeier wrote: >> good news. so your hardware is not the problem. >> iirc, amarok can use a number of audio backends - my guess is it's using >> aRTs (as someone else suggested already). perhaps arts is ok, but messes >> up other program's audio performance? >> > I've disabled aRTs, wired amarok to alsa and it still plays fine. VLC > still chokes on mp3 payback tho. VLC has specific settings for alsa and > oss audio but I haven't found and preference to choose between the two. > Another wierd thing is that /dev/dsp is locked. I can't write to it. Is > this normal if aRTs is done. Are the OSS devices 'emulated' and actually > have ALSA implementation or are they totally different thing ? they are emulated. the driver layer is alsa, and userspace can talk to it either via alsa lib, or the alsa-oss compatibility layer. as to locking, i think /dev/dsp is supposed to be blocking, i.e. when someone accesses it, other tasks that wait for it will go to sleep. except if your hardware supports hw mixing, in which case /dev/dsp can be opened multiple times. but /dev/dsp is OSS-style, alsa applications do not use it. if you can't figure what is accessing it, try lsof /dev/dsp. to narrow things down a bit, can you play wavs glitch-free when using aplay on the command line? that's about as close to alsa-lib as you can get, with no other things in between. then try to experiment with real-time privileges for aplay while it's running (you need to be root, use chrt). -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
