Playing music with other IO

tim-m89

tim-m89

Trying to listen to music through audacious is usually fine, until I try to open a few terminals, csup, compiling etc and then a slight a bit of IO.

Audacious (although I think mplayer has the same issue) will then think it must be at the end of the track and skips to the next in the playlist. It is so distracting and annoying.

Why is freebsd so bad at handling IO in ways that linux and windows have no issue with.

Btw the computer has intel core 2 quad, 4GB ddr2 ram, sata 3Gb so not exactly antique - don't blame the hardware.
 
buganini said:
how about increase buffer size?
Click to expand...

Shouldn't the defaults be suitable enough and if not what size would you recommend a good test? (not crazy 100 mb sort of size buffer). Also would at least double/tripple buffering be used?

I would have thought that an empty buffer would cause a noticeable gap in sound as it hurries to refill but the problem I am having is that it actually think it's the end of the track and will choose next song in playlist or stop if at the end of the pl.

killasmurf86 said:
is there a chance you are using zfs?
Click to expand...

No, freebsd's own fs.
 
hmm, please try mplayer and see if it has same issue....
I don't see anything that could cause lag....

oh, btw, what video driver are you using?
 
On 8.0 amd64 I can play streaming audio (or HD video) in VLC, mplayer and XMMS right through a buildworld/kernel run without a hitch. I have no specific settings in any of these players. So it's not 'FreeBSD per se'. I have snd_hda audio and NVIDIA blob video.
 
killasmurf86 said:
hmm, please try mplayer and see if it has same issue....
I don't see anything that could cause lag....

oh, btw, what video driver are you using?
Click to expand...

Ok tried mplayer. I didn't need to compile anything but just csup alone caused it to think after a few seconds that it was at the end of track 1 and switched to track 2.

I am using snd_hda for audio and I don't use any sort of visualizations for music so didn't expect it to have anything to do with video driver but I am using the latest nvida (the one that for the first time supported freebsd-amd64)
 
Please excuse me if this is seen as nothing more than a bump but this problem is still ongoing for me and since then I have gone from 8.0 release generic to 8 stable with a custom kernel configuration. I still have the issue preventing from listening to music with any other IO because I can be sure that it will frustratingly skip to the next track at some point.

I have also encountered a problem where sometimes copy large files between harddrives (using nautilus but I think the problem lies lower level) it would suddenly stop with an error "no such file or directory". I have noticed the timing of this occurs with the music skipping to the next track too.

I am looking for any insights into what could be the problem as I am stuck without any ideas. My bios is the latest, modern healthy hardware and no ram issues detected so I am interested in exploring problems within the software that handles ahci, ufs, ncq, hd buffers etc.

Thanks.
 
Please check dmesg after you encounter this problem. Also can you post your dmesg after booting verbose (aka boot -v).
 
Sorry but I apologize for saying earlier "freebsd's own fs" but the music is stored on a ntfs partition mounted with ntfs-3g. I tried copy some tracks to my home folder (ufs) and couldn't reproduce the error after a few tries so it looks like the problem is specific to fuse but I was really sure that I already did this test and managed to reproduce the error on ufs.
 
I've had that problem with fragmentation because of heavy-rtorrent-usage and just 2 gigs of ram with zfs. Probably, it was fragmented ntfs problem.
Also, if zfs 'does not need defragmentation' - i do not even now what the heck was going on, because after moving most of files out of partition and then back to it - problem disappeared.
 
Fuse was not originally written with BSD in mind so going from linux's vfs to freebsd vnode based vfs seems to be a lot of hack to re work an existing design. If you have fuse some of it is documented here.

Specifically the problem I encounter is actually known:
When reading/writting the same file repeatedly while doing many simultaneous
operations on different files sometimes the former one fails: read(2) returns
-1 and sets errno to EAGAIN. This is because of a difference between the FUSE
kernel implementation in Linux and FreeBSD, and is being worked on. An example
scenario would be playing a song in XMMS, while building many ports, which
could cause XMMS skip the song. Another observed problem is the current
directory not being found, but entering again would work.
Click to expand...

I guess the RTFM rule doesn't fail but I have doubts in this "being worked on". That README has been there for well over 2 years (feb 2008) and could well have been abandoned. I suppose the do it yourself rule comes next but long standing bugs such as this tend to not have trivial fixes.
 
You must log in or register to reply here.
Back
Top