Thanks for the replies so far :)
Sorry for not replying faster, but here goes:
Emmanuel Jarri wrote:
The workaround I use is to increase buffer size to its maximum, i.e. 13MB,
with 50% to upper pre buffer.
It works quite nicely, but I feel it's a dirty workaround...
My xmms will not go higher than 4096 kb and 90% pre-buffering, and,
unfortunately, those values do not make the temporary freezes go away.
If it worked for me I would also think of it as a dirty workaround :)
Ted Unangst wrote:
> the two solutions are to prescroll the entire playlist (slowly, so
> there are no gaps) or to switch to librthread (which is not done, but
> worked for xmms before anything else). if you haven't heard of
> librthread, then i don't think it'd be good to switch, but the problem
> is being worked on.
Actually, I already use the option "read info on load", so I do not
experience freezes when scrolling my playlist. However, the freezes
appear frequently anyway, e.g. when xmms opens a dialog that reads
directory information from the disk, and therefore still annoys me. I
suspect "my version" of the problem is a bit different from what other
people report, since the execution of heavy programs, such as Mozilla
Firefox and Thunderbird, also disturbs xmms and causes short lags in the
sound.
I have not heard about librthread and would rather like to try another
player than hacking xmms to get smoother sound on my system. Can you
tell me more about what is being worked on and by who?
Doug Clements wrote:
> Check this: http://www.geocities.com/phileosophos/tech/pcilatency.html
Thanks for the link - I found it educational. It presents PowerStrip as
the solution, however, as you might have guessed by now, I am not
running Microsoft Windows :) It makes me wonder how to change the PCI
priorities in OpenBSD... hmm... I will try to look into that. If
somebody knows that this is a wrong path to follow, then please tell me.
/Martin
