Thus spake Axel Thimm ([EMAIL PROTECTED]): > > > Perhaps your network connection is really that bad, that even mp3 > > > streams outperform its bandwidth? > > > > Doubtful. I get around 2MBytes/sec off of the samba share over wireless, > > and around 4 over wired.. > > 4 already looks suspicious, you should get 10 or more. Try ttcp.
4 is probably due to my software RAID5+dmcrypt setup running on shitty hardware. I do not have that much disk bandwidth, unfortunately. It is more than enough to play mp3 (and avi and even vob) locally on the machine without any problems, however. ttcp achieves 3.4Mbytes over wireless, and 10 over wired. Also, I just tested playing mp3s over some shares at work using the same laptop, and both Windows hosted shares and samba (on debian) hosted shares exhibited the same problem. The Debian Samba server took the longest to reproduce: about 30 minutes of continuous play before stopping. This is about as long as NFS took to die on my local setup. Note that my main desktop at work is a Windows XP machine using winamp to listen to the same shares. Winamp has *never* stalled, and I have been on this network for over a year, listening to mp3s almost every day for several hours a day. > > I just tried NFS, and the problem took much longer to reproduce, > > but it did eventually crap out over both the wired and the wireless > > networks. > > > > Think I should also file the bugs with xmms and bmp upstream? Any > > other suggestions? > > No, I don't think this is an application issue. Try cutting out the > apps from the diagnosis by reproducing the error by simple file > copying. I am pretty convinced this is an application issue, especially since now I am able to reproduce it at work. My feeling is that file copying will not reproduce the error because it is due to logic in xmms/bmp expecting unbuffered reads to return in a particular timeframe and in one instance they do not. That, I think, is the bug, and apparently makes xmms/bmp so hypersenstive to timing issues/hiccups that it cannot reliably play mp3s over a network share. I frequently copy files back and forth to the samba share and have never noticed a short file. I do not believe it is likely I will ever do so, either, because copying does not have the time-dependence on reads that xmms does. > Try running gkrellm or a similar monitor on side to your apps and > watch the network traffic. You'll find that when the outages happen > the network traffic will break down. Or if not, it will be from a > different machine congesting your connection to your samba server. It > could be a simple as a dying hdd timing out your read request, so > check the logs on the server, too. I do in fact run gkrellm on both machines. There is never a flat network outage, either when copying or when playing. The setup is a private one, so it is not due to other traffic on the server. There are no hdd errors in the logs, nor any errors in the samba or NFS logs. When copying files, I do see some single-pixel low points in network activity in gkrellm, but never a drop to zero. At worst a drop to 1/2 rate. The last possibility not ruled out is using a different client box. As Warren Togami pointed out on the extras list, it could be my machine is falling victim to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164742 though I do not believe this to be the case... Is anyone playing mp3s over a samba share successfully for long periods of time? I would have thought this would be a common use case.. Maybe people just tend not to use Linux as the client machine.. Or maybe it is my audio drivers after all? Or some other scheduling issue? -- Mike Perry Mad Computer Scientist fscked.org evil labs _______________________________________________ atrpms-users mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/atrpms-users
