streaming dropout

[ed]

strangest thing happened on the way to the forum.....

I've been messing with the main music system to run these seas speakers with DSP. This has meant removing Squeezebox and replacing it with a laptop, in order to run the DSP host(wavelab and latterly foobar).

Although the laptop has some wav files locally I have been streaming from the music server via the same wires that SB uses normally(homeplug network).

I have been getting dropouts...not serious, but dropouts nonetheless. Now to it, I have been raving about homeplugs for the last 5 or 6 years, and today, for the first time, I am suspicious.

I looked at everything I could think of and finally decided to put a trace on the network usage to the laptop.....

here is the trace at the time of the dropout:

[ed]

here is the trace at the changeover between songs, to show the different behaviour....I would not like to blame the homeplugs without much more evidence, but at the moment I can't think of anywhere else to look. The SB never drops out and realtime streaming to the laptop does....I don't know what percentage of the network bandwidth is used by slimserver but I can't imagine it's any more than in realtime(i.e about 1%). All I can think of is that the SB does dropout but because of it's buffering, it's not noticed....

anybody got any ideas??

edit: I should mention that I havn't experienced the problem while using local wav files on the laptop.

[The Stratmangler]

Have you still got Slimserver running ?
If you have then it might possibly be hogging the resources on your NAS.

[ed]

Have you still got Slimserver running ?
If you have then it might possibly be hogging the resources on your NAS.

yes it's still running...I wouldn't have thought it would hog any resource while not playing anything....

but I'll stop it anyway, and see if it makes a difference......

[Nick]

How are you streaming the files. Is it via file sharing? If so, I guess there is nothing in SMB that worries about constant delivery times, the SB will be running with a buffer to handle network gaps, but maybe this way its not.

[ed]

Chris

killed the slim process......and no dropouts since. You may have something, time will tell...thanks for the suggestion.

Nick

I have no idea how the fileshare is configured...The NAS just appears on windows networks on windows machines.....not so straightforward on other linux machines connected to the workgroup. These take a bit of juggling with samba. The visible directory/file structure is configured on the web interface as originally these machines can only be accessed via the web portal. I have since configured other mnt points via telnet which are visible to the network but these have nothing to do with the music streaming.

in the case of wavelab...the file is opened from the menu and I believe the whole file is read into the edit buffer. Obviously no dropout problems with this method.

in the case of foobar I believe it is streamed in realtime with standard i/o buffers, again, opened in the file menu as its visible in the directory structure.....not sure how big the buffers are and not too clued up on foobar config, I will look further at this.

I can't check the share config at the mo because I'm on a borrowed machine and I can't remember the URL for the server portal...oh waily waily

[ed]

I have just found in foobar in menu: advanced/playback there is a setting called 'full file buffering'

I have set this to 50000kb(size of 1 x 5 minute track).

It suggests that this might mimic the operation of wavelab and remove the need for real time streaming. This is certainly born out by the network trace.

The trace shows the moment I pressed play in foobar.

I will see how it goes

[ed]

having played with this over the last couple of weeks I have concluded:

full file buffering removes dropout(obviously) but is not really practical because it can take 20-30 secs to load between tracks

By juggling with foobar network and output buffer sizes the problem can be eliminated.......not sure what the optimum is but:

network at 1024

and

output at 5000ms

works ok for me.......not very scientific I know but considering only 1% of the network bandwidth is used I think I am covering for inefficiencies somewhere else, e.g the NAS engine

[The Stratmangler]

works ok for me.......not very scientific I know but considering only 1% of the network bandwidth is used I think I am covering for inefficiencies somewhere else, e.g the NAS engine

Which is why I suggested turning off Squeezecenter.
From posts on the Squeeze forum it appears that quite a few NAS devices capable of running Squeezebox Server are at the edge of their capacity when doing so - you might find that things grind to a halt were you to try the latest 7.5.5 version.

[Neal]

This one has caught me out as well: http://forums.slimdevices.com/showthread.php?t=87973

In case anybody else has rebuffing issues when streaming...

[pre65]

Think I'll stick with the real thing.(ie CDs).

[ed]

works ok for me.......not very scientific I know but considering only 1% of the network bandwidth is used I think I am covering for inefficiencies somewhere else, e.g the NAS engine

Which is why I suggested turning off Squeezecenter.
From posts on the Squeeze forum it appears that quite a few NAS devices capable of running Squeezebox Server are at the edge of their capacity when doing so - you might find that things grind to a halt were you to try the latest 7.5.5 version.

I think we've been through this before Chris....

I did take slimserver out, as you suggested, but I still got dropouts until I fiddled with the buffers.

We have discussed the software before, the latest slim I can use is 6.2.2 because of the sql limitations(it runs sqlite).....my box is dual fuel, when the steam runs out the elastic band takes over...

Anyway it's all academic because I was only using it to measure some speaker responses using a dsp, it's back to the squeezebox now.

[Mike H]

.....my box is dual fuel, when the steam runs out the elastic band takes over...