PDA

View Full Version : Need Help with Poor Buffer Filling and Dropouts



bec143
2005-10-31, 09:01
I have been discussingmy dropout problems in the Audiophile forum, but I think this is better here, aince I may have noe new info.

I am running a wireless SB2 on a Mac system with an Airport Exreme. I have been plagued by dropouts, and have gone through many many suggestions, but to no avail. This onlyhappens with ripped CDS (Apple Lossless, AIFF, AAC-all the same). Internet radio works like a charm.

Well I finally set it up to continuously monitor the bufer while it is playing. I found that sometimes in mid-song the buffer gradually drops to 0% over a short time, and that's when the continous dropouts happen- and the buffer stays at 0% during this time. The signal strength has not changed when this happens, or when the buffer stays at 0%, and the wireless network is working otherwise during this time.

What might account for this, and how do I fix it??

Thanks,

Bruce

danco
2005-10-31, 09:38
On 31/10/05 at 08:01 -0800, bec143 wrote
>I have been discussingmy dropout problems in the Audiophile forum, but I
>think this is better here, aince I may have noe new info.
>
>I am running a wireless SB2 on a Mac system with an Airport Exreme. I
>have been plagued by dropouts, and have gone through many many
>suggestions, but to no avail. This onlyhappens with ripped CDS (Apple
>Lossless, AIFF, AAC-all the same). Internet radio works like a charm.
>
>Well I finally set it up to continuously monitor the bufer while it is
>playing. I found that sometimes in mid-song the buffer gradually drops
>to 0% over a short time, and that's when the continous dropouts happen-
>and the buffer stays at 0% during this time. The signal strength has
>not changed when this happens, or when the buffer stays at 0%, and the
>wireless network is working otherwise during this time.
>
>What might account for this, and how do I fix it??

Probably accounted for by something taking all the CPU for a while.
I'm told that some widgets do that (if you are using Tiger). More
worryingly, some useful processes (maybe even perl) can do it. And
refreshing the Web browser (particularly if pointed at the SlimServer
page) can have that effect.

But none of this really explains why this only happens on CDs.
--
Daniel Cohen

bec143
2005-10-31, 09:59
Maybe, but I have everything shut off, and like no widgets, and 1.25 Gigs of RAM.

Craig, James (IT)
2005-10-31, 10:02
Are you running any plugins?

I would check the performance at the server end while the dropouts occur
- it could be a burst of CPU usage from SlimServer itself rather than
any other process.

Not being a mac user I have no idea how you do this though...

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

Patrick Dixon
2005-10-31, 10:45
Just try disabling all the plugins you're not actually using - you should be able to disable pretty much all of them - and see if this helps. The buffer does run down to 0% towards the end of a track, but should pick up again to 100% within a couple of seconds, without interrupting the music.

afblaster
2005-10-31, 11:35
I have experienced exactly the same problem, with nothing else apart from SlimServer running on my (windozeXP) PC.
The wireless network activity looked normal and the signal strength was Ok. I changed the wireless network channel from 11 (default) to 2, and this fixed it. Hope this helps.

Richard

bec143
2005-10-31, 13:17
But this happens even wihtout using a web interface, and with no other applications running. Are their any plug-ins I need to watch for if the only thing running is the Slimserver?

Bruce

Triode
2005-10-31, 13:30
Are you using 6.2? If so can I suggest you look at the "Network and Server Health" web page - accessed from the Help section of the
main page.

Once performance monitoring is turned on, it monitors the performance of the server and network connection in the background. Play
some music to allow it to collect data and then look at the graphs.

If the "Response time" graph shows occasional long responses times then your problem may be due to this. Otherwise I would suspect
a network problem.

Post the graphs here if you want a diagnosis of what they are saying.

>
> But this happens even wihtout using a web interface, and with no other
> applications running. Are their any plug-ins I need to watch for if
> the only thing running is the Slimserver?
>
> Bruce

bec143
2005-10-31, 18:53
Tride-\\Most of the time it looks like this

10.0.1.5

Please queue up several tracks to play on this player and start them playing. Then press the Reset Counters link above to clear the statistics and update this display.

Summary

Control Connection : OK
Streaming Connection : OK
Player Signal Strength : OK
Buffer Fullness : Low
Server Response Time : OK

Warnings

The playback buffer for this player is occasionally falling lower than ideal. This is a Squeezebox2 and so the buffer fullness is expected to drop at the end of each track. You may see this warning if you are playing lots of short tracks. If you are hearing audio dropouts, please check our network signal strength.

Player Performance : 10.0.1.5

The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.

It is imporant to leave the player playing for a while and then assess the graphs.


Player Signal Strength

This graph shows the strength of the wireless signal received by your player. Higher signal strength is better. The player reports signal strength while it is playing.
< 10 : 0 : 0%
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 0 : 0%
< 50 : 0 : 0%
< 60 : 1 : 50% #########################
< 70 : 1 : 50% #########################
< 80 : 0 : 0%
< 90 : 0 : 0%
< 100 : 0 : 0%
>=100 : 0 : 0%
max : 60.000000
min : 58.000000
avg : 59.000000
Buffer Fullness

This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.
Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

< 10 : 2 :100% ##################################################
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 0 : 0%
< 50 : 0 : 0%
< 60 : 0 : 0%
< 70 : 0 : 0%
< 80 : 0 : 0%
< 90 : 0 : 0%
< 100 : 0 : 0%
>=100 : 0 : 0%
max : 0.081539
min : 0.008774
avg : 0.045156
Server Performance

The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time

This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.
The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

< 0.002 : 36 : 53% ##########################
< 0.005 : 23 : 34% ################
< 0.01 : 2 : 3% #
< 0.015 : 2 : 3% #
< 0.025 : 2 : 3% #
< 0.05 : 2 : 3% #
< 0.1 : 1 : 1%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.055966
min : 0.000441
avg : 0.004498
Timer Accuracy

Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.
Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

< 0.002 : 4 : 50% #########################
< 0.005 : 0 : 0%
< 0.01 : 1 : 12% ######
< 0.015 : 2 : 25% ############
< 0.025 : 0 : 0%
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 1 : 12% ######
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.131937
min : 0.000243
avg : 0.020876
Timer Task Duration

This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.
< 0.002 : 5 : 62% ###############################
< 0.005 : 2 : 25% ############
< 0.01 : 0 : 0%
< 0.015 : 1 : 12% ######
< 0.025 : 0 : 0%
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.011042
min : 0.000237
avg : 0.002505

bec143
2005-10-31, 19:26
Server & Network Health


Performance monitoring is currently enabled on your server. Performance statistics are being collected in the background while your server is running.

Disable Performance Monitoring

Reset Counters

Update Page


10.0.1.5

Please queue up several tracks to play on this player and start them playing. Then press the Reset Counters link above to clear the statistics and update this display.

Summary

Control Connection : OK
Streaming Connection : OK
Player Signal Strength : OK
Buffer Fullness : Low
Server Response Time : Occasional Poor Response

Warnings

The playback buffer for this player is occasionally falling lower than ideal. This is a Squeezebox2 and so the buffer fullness is expected to drop at the end of each track. You may see this warning if you are playing lots of short tracks. If you are hearing audio dropouts, please check our network signal strength.

Your server response time is occasionally longer than desired. This may cause audio dropouts, especially on Slimp3 and Squeezebox1 players. It may be due to background load on your server or a slimserver task taking longer than normal.

Player Performance : 10.0.1.5

The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.

It is imporant to leave the player playing for a while and then assess the graphs.


Player Signal Strength

This graph shows the strength of the wireless signal received by your player. Higher signal strength is better. The player reports signal strength while it is playing.
< 10 : 0 : 0%
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 0 : 0%
< 50 : 0 : 0%
< 60 : 379 : 44% ######################
< 70 : 475 : 56% ###########################
< 80 : 0 : 0%
< 90 : 0 : 0%
< 100 : 0 : 0%
>=100 : 0 : 0%
max : 68.000000
min : 53.000000
avg : 60.134660
Buffer Fullness

This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.
Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

< 10 : 741 : 88% ###########################################
< 20 : 15 : 2%
< 30 : 7 : 1%
< 40 : 7 : 1%
< 50 : 6 : 1%
< 60 : 6 : 1%
< 70 : 7 : 1%
< 80 : 5 : 1%
< 90 : 9 : 1%
< 100 : 41 : 5% ##
>=100 : 0 : 0%
max : 99.989001
min : 0.000000
avg : 8.344904
Control Connection

This graph shows the number of messages queued up to send to the player over the control connection. A measurement is taken every time a new message is sent to the player. Values above 1-2 indicate potential network congestion or that the player has become disconnected.
< 1 : 161 :100% ##################################################
< 2 : 0 : 0%
< 5 : 0 : 0%
< 10 : 0 : 0%
< 20 : 0 : 0%
>=20 : 0 : 0%
max : 0.000000
min : 0.000000
avg : 0.000000
Server Performance

The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time

This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.
The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

< 0.002 : 12298 : 65% ################################
< 0.005 : 5010 : 27% #############
< 0.01 : 704 : 4% #
< 0.015 : 220 : 1%
< 0.025 : 197 : 1%
< 0.05 : 208 : 1%
< 0.1 : 171 : 1%
< 0.5 : 45 : 0%
< 1 : 5 : 0%
< 5 : 1 : 0%
>=5 : 2 : 0%
max : 10.075311
min : 0.000178
avg : 0.004771
Timer Accuracy

Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.
Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

< 0.002 : 1426 : 82% #########################################
< 0.005 : 101 : 6% ##
< 0.01 : 95 : 5% ##
< 0.015 : 22 : 1%
< 0.025 : 19 : 1%
< 0.05 : 37 : 2% #
< 0.1 : 17 : 1%
< 0.5 : 13 : 1%
< 1 : 3 : 0%
< 5 : 1 : 0%
>=5 : 5 : 0%
max : 9.897123
min : 0.000021
avg : 0.033046
Timer Task Duration

This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.
< 0.002 : 884 : 51% #########################
< 0.005 : 676 : 39% ###################
< 0.01 : 153 : 9% ####
< 0.015 : 12 : 1%
< 0.025 : 6 : 0%
< 0.05 : 2 : 0%
< 0.1 : 4 : 0%
< 0.5 : 2 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.133395

CardinalFang
2005-11-01, 02:40
I would check the performance at the server end while the dropouts occur - it could be a burst of CPU usage from SlimServer itself rather than any other process.

I have the same issue and it is definitely SlimServer CPU usage. In my case it was down to playing music on iTunes at the same time. I had an iTunes plugin running that gets album art for songs and it was updating iTunes on every song. That was causing SlimServer to constantly trigger library scans.

There is a monitoring facily in the utilities directory of applications on the Mac called Activity Monitor. I used it to track down that the buffer going to zero and stuttering was down to Perl running all the time - and SlimServer is the only Perl app running, so that led to my conclusion that it is constantly doing rescans.

I have disabled every possible triggering of automatic library rescans - hopefully that will improve things.

Paul

bec143
2005-11-01, 07:33
Paul,

That's a vert good idea. I just checked on the activity monitor as the buffer emptied, and the CPU was still about 40% idle with a few appsa nd widgets running. It was interesting to see how much those widgets (now disabled) took. I got it down to basically only the Perl as well (the slimserver) and I'll check it out again, but sems like the CPU still had some capcity. Moreover, the slimserver log I pasted seems to show that th CPU rsponse time as fine, but maybe I'm reading that wrong.

Bruce

Triode
2005-11-01, 12:09
This suggests the server response time is fine. Just to confirm what you are looking at,

This says that during the period it was monitoring, the server response time (time between trying to service each player) only
exceeded 5 seconds twice. Normally it is less than 5 milliseconds [65+27% of time] with only 1 case over 1 second and 2 cases over
5 seconds. The max time is 10 seconds.

With an SB2 I would not expect this to cause problems. The 10 second case could cause a problem, but I suspect is a one off
probably due to building a web page.

The other numbers (buffer fill etc) don't look like they have been reset since you started playing. If you queue up a few songs and
set the player playing through them and then reset the counters, you sould get the stats for the player including the buffer fill.
This is expected to drop to zero as one track stops and another starts, but otherwise I would expect it to reach 100%

Based on this info thus far I suspect network problems which are not reported as reduced signal strength. But feel free to post
some more after resetting the counters as above.

>
> < 0.002 : 12298 : 65% ################################
> < 0.005 : 5010 : 27% #############
> < 0.01 : 704 : 4% #
> < 0.015 : 220 : 1%
> < 0.025 : 197 : 1%
> < 0.05 : 208 : 1%
> < 0.1 : 171 : 1%
> < 0.5 : 45 : 0%
> < 1 : 5 : 0%
> < 5 : 1 : 0%
>>=5 : 2 : 0%
> max : 10.075311
> min : 0.000178
> avg : 0.004771

dwc
2005-11-01, 12:16
I have had some seemingly random 'descending to zero' buffer issues, and still get them. It seems I can clear the situation by backing out of that song and starting another song somewhere else in the folder structure. Then go back to that song and try again.

Leads me to believe it's not the network strength. It may be a cpu issue, but since I can work around it I haven't dug into it deeply.

-Dan

Triode
2005-11-01, 12:31
Can you give more details - it may be that we can add some more debugging to identify it.

What server hardware, OS and version are you running. What happens to the song, does the next one in the playlist play?

Adrian

----- Original Message -----
From: "dwc" <dwc.1xu1fb (AT) no-mx (DOT) forums.slimdevices.com>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, November 01, 2005 7:16 PM
Subject: [slim] Re: Need Help with Poor Buffer Filling and Dropouts


>
> I have had some seemingly random 'descending to zero' buffer issues, and
> still get them. It seems I can clear the situation by backing out of
> that song and starting another song somewhere else in the folder
> structure. Then go back to that song and try again.
>
> Leads me to believe it's not the network strength. It may be a cpu
> issue, but since I can work around it I haven't dug into it deeply.
>
> -Dan
>
>
> --
> dwc
>

bec143
2005-11-01, 13:37
Adrian,

The first set of data I posted was just after I reset the counter, and the second was fater it skipped for a while.

I'm using a 1.5 GHz G4 Powerbook, 1.25 Gb RAM, and running Tiger.

Bruce

Triode
2005-11-01, 17:01
OK - what file type are you playing and do you have bitrate limiting enabled?

>From the graphs I would say the server is OK as other than the 2 periods of > 5 seconds all is very responsive.

The buffer fullness graph is low though. It should be 100%, appart from when if drains out at the end of a file. (how long was it
playing for when you took this?)

Have you tried running with a wired connection (even just moving the Squeezebox and rerunning this test would record whether the
buffer fullness stays higher - you don't need to listen to it!) It does look like it is a wireless problem to me at present.

Adrian
----- Original Message -----
From: "bec143" <bec143.1xu54n (AT) no-mx (DOT) forums.slimdevices.com>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, November 01, 2005 8:37 PM
Subject: [slim] Re: Need Help with Poor Buffer Filling and Dropouts


>
> Adrian,
>
> The first set of data I posted was just after I reset the counter, and
> the second was fater it skipped for a while.
>
> I'm using a 1.5 GHz G4 Powerbook, 1.25 Gb RAM, and running Tiger.
>
> Bruce
>
>
> --
> bec143
>

bec143
2005-11-01, 17:24
It happens with Apple Lossless, AIFF, and even regular AAC files. I haven't done anything with the bitrate- where do I find it and what should it be?

CardinalFang
2005-11-02, 00:48
I just checked on the activity monitor as the buffer emptied, and the CPU was still about 40% idle with a few appsa nd widgets running. Bruce

Disabling all the automatic rescans fixed it for me - I also took some memory out of an old PC and stuffed it in the Mac (an old PowerMac G4) and that helped responsiveness a *lot*.

It seems that the 6.2 rescan is very slow and I would strongly suspect that all the drop outs on your system are due to rescans taking place.

Paul

oreillymj
2005-11-02, 04:00
I suspect but cannot prove that the SB2 may sometimes switch itself down into 802.11b mode.
Or it could be that during times of heavy Wireless interference it may change it's speed downward to maintain a reliable link, but then never tries to bump the speed back up again.

My experience is that MP3's will stream just fine from my PC to the SB2 over Wireless, but FLAC's only work intermittently. Most of the time I get dropouts. Then I pause and resume playback, the buffer fullness indicator shows 90% but quickly begins dropping in 10% increments until it gets to 0% and playback begins to break up.

I switched on protected mode on my Belkin Wireless Router and this temporarily fixed things. I was able to stream a 65mb flac encoded DTS file without break up. The next day, without changing anything, I was back in dropout hell.

I know there is ample bandwith on my Wirelees network to do this streaming. My T42 thinkpad can copy a 45mb file from my PC through the same router in < 1 minute over the same network, through the same router.

I'd like to see the SB2 display some realtime Wireless network info such as protocol (802.11b or 802.11g) and speed. Depending on the Wireless chipset in use, the speed will dip to point where the traffic can be maintained reliably. But the amount the speed will drop also depends on the values supported by the Wireless router the client is talking to. AFAIK, the client also needs to try up it's speed when the reception improves.

mlmurray
2005-11-02, 07:47
Just my $0.02, but I have been experiencing similar dropouts when streaming flacs and oggs (via pcm) to my SB1.

After some headscratching I discovered it was related to the SlimScrobbler auto submission (in the middle of songs). When the Last.FM site is slow (which seems to happen often in the evenings), it caused dropouts in my high bandwidthd streams - not with mp3's, though (I assume that the SB1 has enough of the mp3 already in it's cache that it can stand the 2-3 second lag).

All this (as well as the solution) was pointed out in the README file that comes with the slimscrobbler plugin. If you're running that plugin, you may want to check into this if you haven't already pinned down your problem.

vordo@vordo.org
2005-11-02, 10:43
check to see if 'perl' is going crazy during the dropouts. I have found that I am getting less dropouts with the 6.5 betas than on 6.2 or 6.1. it seems that perl is more chilled in the 6.5.

Triode
2005-11-02, 11:55
Ok all of these are currently using quite high bandwidth on your wireless network.

If you install lame and enable bitrate limiting [Player Settings - Audio - Bitrate Limiting] then the server compresses the stream
into mp3 so it needs less bandwidth from the network connection. This does reduce quality, but will prove that it is the network
which is causing the problem if it works OK at reduced bitrate.

NB if you have not done it before you need to install lame as it does not come with the server. [I think the server faw says where
it should go]

>
> It happens with Apple Lossless, AIFF, and even regular AAC files. I
> haven't done anything with the bitrate- where do I find it and what
> should it be?
>

bec143
2005-11-02, 13:45
I did install Lame, and did the bitrate restriction to 320 last night. The player indicated that LAME was installed correctly. It did run better for a while, but after two songs, the buffer once again dwindeled to 0% (from a high of about 35%) and then essentially never recovered, and stuttered constantly. Atthat time I checked the internet radio, which was still working fine.

I also downdraded my Airport formware to 5.5.1 because of a suggestion made from Slim technical support, but this didn't really help much.

If I am ever really going to use this, it needs to be able to stream umcompressed audio, since I am trying to replace a pretty god Naim CDP. i had planned to add an external DAC, but obviously not if I can't get the thing to work!

Thanks,
Bruce

bec143
2005-11-02, 13:54
Could you point me specifically in the drection of where the boxes to disable the rescans are? I can't find any, except on rescan option in the server settings that doesn't seem to include a disable option.

Not running SlimScrobbler, btw.

Bruce

Triode
2005-11-02, 13:55
Have you tried flac encoded files ? Could I suggest you rip a CD to flac and try this. The reason is that the server computer does
much less work sending a stream to the client than converting it and then sending it. The data we looked at before with the
performance monitoring plugin is for the server process itself, it does not say what the external processes required to convert
streams are doing.

>
> I did install Lame, and did the bitrate restriction to 320 last night.
> The player indicated that LAME was installed correctly. It did run
> better for a while, but after two songs, the buffer once again
> dwindeled to 0% (from a high of about 35%) and then essentially never
> recovered, and stuttered constantly. Atthat time I checked the
> internet radio, which was still working fine.
>
> I also downdraded my Airport formware to 5.5.1 because of a suggestion
> made from Slim technical support, but this didn't really help much.
>
> If I am ever really going to use this, it needs to be able to stream
> umcompressed audio, since I am trying to replace a pretty god Naim CDP.
> i had planned to add an external DAC, but obviously not if I can't get
> the thing to work!
>

bec143
2005-11-02, 15:17
We are now verging on the fringes of my knowledge. iTunes doesn't do FLAC, is there a user friendly MAC FLAC ripper that can be used with iTunes?

I had thought that AIFF could be streamed as AIFF without any conversion?

vordo@vordo.org
2005-11-02, 15:30
We are now verging on the fringes of my knowledge. iTunes doesn't do FLAC, is there a user friendly MAC FLAC ripper that can be used with iTunes?

I had thought that AIFF could be streamed as AIFF without any conversion?

actually apple lossless is a flavor of FLAC.

Triode
2005-11-02, 15:30
Yes, sorry AIFF should stream with no extra server work, so if this gives the same problems and the server response is still fine,
the network has to be the focus of your attention.

Do you see the same symptoms for all of them?

Have you tried a wired connection (even with headphones or just looking at the buffer fill chart) We really need to know if this
works without dropouts.
----- Original Message -----
From: "bec143" <bec143.1xw4fb (AT) no-mx (DOT) forums.slimdevices.com>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Wednesday, November 02, 2005 10:17 PM
Subject: [slim] Re: Need Help with Poor Buffer Filling and Dropouts


>
> We are now verging on the fringes of my knowledge. iTunes doesn't do
> FLAC, is there a user friendly MAC FLAC ripper that can be used with
> iTunes?
>
> I had thought that AIFF could be streamed as AIFF without any
> conversion?
>
>
> --
> bec143
>

bec143
2005-11-02, 22:46
So I did something obvious tonight that had eluded me before. I simply left my Powerbook onmy Airport Network, and ran an ethernet cable from my laptop to the SB2, no running the SB2 from the cable instead of the network. 100% buffer filling immediately, no dropouts, and I can still use the web interface on the Slimserver. I have no porblem running a cable from my laptop to the SB2,so I guess that's the end of it all.

Still no idea why the Airport won't work, but I'm sick off it all.e

Bruce