PDA

View Full Version : Unbearable rebuffering with poor quality internet radio streams (7.7.1)



nicolas75
2012-01-02, 08:52
Squeezeboxes have always had a lot of problems with bad quality radio streams.
However it seems worse with 7.7.1 than with previous versions.

There was this bug http://bugs.slimdevices.com/show_bug.cgi?id=3161 , now closed, which was about replay simply stopping when there is a problem.

During last days, I was listening to some internet radio streams with temporarily bad quality.
Those were almost impossible to listen with Squeezebox Touch.
You get several seconds rebuffering about every minute or so.

I was curious to try to listen to the same stream with PC players (MediaMonkey, Foobar, etc ...)
With those softwares, you can hear some artefacts sometimes, but you can really listen to the stream without real annoyance.
At the same time, I could see the rebuffering messages on the Touch screen, showing that you cannot listen to the stream with the Touch without getting mad ...

Is there some testing done from Logitech development, as far as radio streams stability is concerned ?

It should not be that hard to generate on purpose a not perfect mp3 stream, and see if squeezeboxes behavior is acceptable.

(Touch is wired, internet connection excellent, this is the stream which is sometimes unstable).

bpa
2012-01-02, 08:55
Have you tried increasing the "Radio Station Buffer Seconds" ? It increases startup time but it may help smooth over a lumpy internet streams.

nicolas75
2012-01-02, 09:01
Have you tried increasing the "Radio Station Buffer Seconds" ? It increases startup time but it may help smooth over a lumpy internet streams.

No, but the behavior is so bad compared to PC players replay that it cannot be only a matter of LMS settings.
Since replay is stopped during rebuffering, I would even think that increasing this number should make things even worse.

aubuti
2012-01-02, 09:15
No, but the behavior is so bad compared to PC players replay that it cannot be only a matter of LMS settings.
Since replay is stopped during rebuffering, I would even think that increasing this number should make things even worse.
The setting specifies the number of seconds of audio held in the buffer. So increasing the number of seconds increases the size of the buffer, and therefore decreases the interruptions. That is, if the stream is interrupted, there is more audio in the buffer to keep playing until the stream resumes.

The default setting in LMS is 3 seconds. If MM, foobar2K or others have larger buffers that would easily explain the different behavior.

nicolas75
2012-01-02, 09:19
That is, if the stream is interrupted, there is more audio in the buffer to keep playing until the stream resumes.


This is exactly why I said that I expect that increasing this number will make things even worse ...
[Edit : more audio in the buffer means more seconds needed to rebuffer, and since replay is stopped while rebuffering ...]

nicolas75
2012-01-02, 09:21
If MM, foobar2K or others have larger buffers that would easily explain the different behavior.

Those softwares obviously don't work in the exact same way (which cannot give good results).
They do not stop replay while rebuffering occurs.

aubuti
2012-01-02, 09:32
This is exactly why I said that I expect that increasing this number will make things even worse ...
[Edit : more audio in the buffer means more seconds needed to rebuffer, and since replay is stopped while rebuffering ...]
Replay stops when the buffer is empty. If you have a bigger buffer, there is less chance of the buffer becoming empty.

Have you tried increasing the internet radio buffer size? What stream is it that is giving you problems?

nicolas75
2012-01-02, 09:38
Replay stops when the buffer is empty. If you have a bigger buffer, there is less chance of the buffer becoming empty.

Have you tried increasing the internet radio buffer size? What stream is it that is giving you problems?

When the stream is bad, you will necesseraly experience rebuffering.
Increase the buffer, and you well get rebuffering every 3 (or whatever figure depending of the size increase) minutes instead of every minute, and each rebuffering will be awfully long (3 seconds is not acceptable user experience, it is too long).


The problem is not the size of the buffer, the problem is that replay stops during rebuffering.
This is a well known problem for streaming software developpers.

bpa
2012-01-02, 11:06
When the stream is bad, you will necesseraly experience rebuffering.
Increase the buffer, and you well get rebuffering every 3 (or whatever figure depending of the size increase) minutes instead of every minute, and each rebuffering will be awfully long (3 seconds is not acceptable user experience, it is too long).


The problem is not the size of the buffer, the problem is that replay stops during rebuffering.
This is a well known problem for streaming software developpers.

Not necessarily - if the source is overloaded and it gives bursts of audio say of about 10 secs burst once every 8-10 secs, if your buffer setting is 15 secs it will play smoothly but if your buffer setting is 5 secs it will stop.

Stations which play in realtime (i.e. live broadcast) will always give problems as they have to resync with realtime every so often. For example, if stream gets behind realtime by say 10 secs due to network load and stations has to give a time signal at x O'clock for news, the station will drop packets in the audio stream.

nicolas75
2012-01-02, 11:52
Well, Foobar buffer length is 1000 ms on my computer.
I can't remember having ever heard 1 second abrupt silence while listening radio stream with Foobar, and I guess you can hardly miss it if it happens.

Today I listened to the same stream, switching between Foobar, MediaMonkey and Squeezebox Touch.

the result was

- some audio artefacts showing poor stream with Foobar and MediaMonkey, but nothing really preventing you from acceptable listening, and no abrupt silence whatsoever.

- Unbearable rebuffering, lasting several seconds (replay completely stops meanwhile), at least once a minute, often even more frequent, with the Touch.

I have been using Squeezeboxes for several years, and started before Logitech aquired Slimdevices.
The 2 main problems with squeezeboxes have always been

1/ scanning reliability
2/ rebuffering problems


I can hardly imagine LMS is tested against poor streams in order to check its reliability.
Is there really some basic testing done concerning rebuffering before public release ?

gerph
2012-01-02, 12:35
When the stream is bad, you will necesseraly experience rebuffering.
Increase the buffer, and you well get rebuffering every 3 (or whatever figure depending of the size increase) minutes instead of every minute, and each rebuffering will be awfully long (3 seconds is not acceptable user experience, it is too long).

The problem is not the size of the buffer, the problem is that replay stops during rebuffering.
This is a well known problem for streaming software developpers.

This depends, partly, on the protocol used to deliver the stream. If the streaming protocol allows for missing sections of data (such as delivery by UDP), or changes its delivery based on performance (such as adaptive rate streaming), then these problems occur less, but this is not usually the case with radio stations. Knowing what station you were having problems with, and therefore what the protocol used for delivery was, would help to identify if either of these are the issue.

However, for HTTP based streaming - which is common, whether it utilises the plain HTTP stream or the ICY variant - this is TCP based, so the former method used to skip data isn't possible. Except by stream reconnection, and that usually results in a greater interruption due to the streams being desynchronised (possibility of repeating or skipping sections), and TCP having a slower start due to its own connection and protocol. Plus, if the problem is at the local end, initiating a secondary connection will slow the first, exacerbating the problem.

You suggest in your first comment that the problem is a corrupt MP3 stream. If the stream were corrupt, then that is an issue for the source to address, and its much less likely that the player is at fault. Corrupt MP3s can produce rebuffering indications and the like, but you are far more likely to hear blips and squeals in the audio than see rebuffering indications.

Your last comment suggests a lack of understanding of the process is used during the playback, and the way that players handle bursty or otherwise bad connections - if its just the phrasing that I've taken the wrong way then I'm sorry. Streaming players are always buffering data as it arrives. There may be multiple layers of buffering taking place which affect the stream. For example, TCP based connections (such as those used by HTTP) have their own internal buffers (so do UDP, but I'm focusing on the TCP as HTTP is more common and it follows to the next point).

The internal TCP buffers can be varying sizes and are there for 2 reasons - firstly they allow the receiving application to do other things whilst blocks of data are received. Secondly, the allow the data to arrive in different orders and be resequenced. This latter part of sometimes a logically separate buffer to the former, as out-of-order data has NOT (from the player's point of view) been received yet (that's just the way that TCP is - you get everything in order, which is why you cannot skip sections, as you might with UDP based protocols).

So, in the case of a 'bad' stream, you might be experiencing packet drop - if connections in between are dropping packets then only some will arrive at the client and those that are not received will be waited for. If they do not arrive then a 'retransmit request' will be sent to ask for that data. This takes a while - depending on the TCP configuration, the retransmit delay might be a few seconds.

At this point it is important to also include the fact that the 'client' in the streaming may not be the server. In some cases, the Squeezebox itself is capable of performing the streaming itself without the interaction of the server - at least that's what I remember from looking into it some time back and I accept that my memory may be flakey. So it might be important to know which Squeezebox model you are streaming to - I don't know whether the Touch will perform streaming directly or not.

Ok, so you've got TCP buffering involved. Then there is the application level buffering which may be in two forms - input data (how much has just been streamed and needs decoding) and output data (how much is available to play). As the buffer size in the server is measured in seconds, it is reasonable to assume that the buffer being configured is the output buffer.

As the data arrives it is buffered (by TCP and then by the application input buffer).
It is then decoded into playable data and buffered in the output buffer for playback.
When the output buffer is full (to your configured level) playback starts.
All the time the output buffer is draining all the time that playback is happening.
As time progresses more data will arrive - maybe in small bursts either because of delays in delivery or packet loss - and all the time the output buffer is being drained of data as it is playing.

*When the output buffer is empty, playback stops* (and you are usually presented with a 'rebuffering' message)

This is why, as you say "replay stops during rebuffering". There is NO data to play, so there is no way to play anything. As data arrives and reaches your configured buffer size, playback will resume. If you want playback to start sooner, you configure the buffer size *down* - this means that as soon as there is that much data available it will play it. However, when that data runs out, playback will stall, so with a poor connection that could not keep up, you will be interrupted more often. Which is just a fact - if the data coming over the network cannot be delivered sufficiently quickly to keep up with realtime it will always drop out.

If you have a *larger* buffer then any temporary delays in the stream (because of packet loss, or slower delivery) will be smoothed out. The streaming server will attempt to keep up to real time, so the data should (if it was only a /temporary/ delay) catch up later in the stream, thus re-filling the buffers. The larger buffer smooths out the temporarily delayed data. If it never does catch up then the output buffer will drain completely and you'll get a 'Rebuffering' message.

If, for example, you have a 3 second buffer configured then it will take 3 seconds for your stream to start, and you will be running 3 seconds behind real time. If you get a 'rebuffering' message, that means that the stream couldn't keep up with realtime and is now running 3 seconds behind.

There may be issues outside of the buffering which are at fault, but without more information on the station you have problems with, suggesting a change of buffer size is the best bet.

There was a way to see the buffering level, but I cannot seem to find it on my player at the moment - maybe someone else can suggest something. Or maybe it only exists on certain configurations or players.

You suggest that there are other players that "do not stop playing when rebuffering occurs", and as you suggest, these may not work the same way. I would suggest that if they keep playing whilst displaying a 'rebuffering' message what they mean is that their output buffer has drained below a limit and they are now *warning* you that you're running out of data and there is data being buffered.

Alternatively they could have a large output buffer /beyond/ that used by the application. For example, DirectSound might be buffering a few seconds of data, so whilst your PC players have no output data to hand off to the DirectSound system (or equivalent, if you're using a non-Windows system) and are therefore in need of rebuffering, there is still sound coming out of the speakers.

So whilst, yes, those application may be working differently to the Squeezebox - they're merely reporting that they are rebuffering when there it still data available to them, whereas the Squeezebox is reporting that it is rebuffering only at the point that it has actually run out of data.

nicolas75
2012-01-02, 13:09
...
You suggest that there are other players that "do not stop playing when rebuffering occurs"
...

Well you gave a tremendous amount of technical explanations, very interesting for technical guys and developers.
The problem is not to explain to squeezeboxes users what is the theory of streaming and protocols.
I can easily understand that stuff, but the point is not to explain "WHY" LMS behavior is not user friendly in this particular case (users don't really care), but to understand that there "IS" a problem with squeezeboxes and rebuffering (at least users can hope the problem may be handled, if it is at least acknowledged).

Rebuffering has always been a big problem with squeezeboxes.

I am not "suggesting" anything.
This afternoon, I experienced for several hours a technical problem on a radio stream I listen almost every day, usually without problems.

It gave me time enough to check that this problem

1/ made the stream awfully unlistenable with Squeezebox.
2/ was not such a big problem with every other mean I tried to listen to it.

So that Squeezebox "IS" the problem there, because it cannot handle faults easily handled by other systems.

My question was not really to find the reason for this problem, but to know if there is some testing done as far as LMS reliability against poor streams is concerned.

Most people having rebuffering problems with squeezeboxes usually get advice suggesting that this is more or less normal, and that it is everything but software "bug" or let's say "user highly unfriendly behavior".

Today I unquestionably checked that LMS Squeezebox Touch has a big problem with a "poor" stream, while popular softwares do not.

The first thing to fix this kind of problem, is not to ask people to provide a testcase they cannot provide, but to start to have some in-house testcase generating "poor" streams , and check against those.

I wonder if this is done at Logitech's, because the behavior I experienced today seems to me a common problem, though usually not that dramatic, which appear again and again on various occasions.

nicolas75
2012-01-02, 13:14
You can check here

http://bugs.slimdevices.com/show_bug.cgi?id=3161

that it was really hard to convince technical people that squeezebox behavior was a complete nonsense for any normal user for this bug specific problem (not the same than rebuffering) ...

toby10
2012-01-02, 13:32
What station is causing this? What is the stream format? Tried connecting directly to MySB (maybe taking LMS and/or other things out of the loop might help)?
Other Touch users can try it to compare results.

nicolas75
2012-01-02, 13:57
What station is causing this? What is the stream format? Tried connecting directly to MySB (maybe taking LMS and/or other things out of the loop might help)?
Other Touch users can try it to compare results.

I tried MySB, TinySBS, LMS, same result

Everything is fine now, problems were especially big and lasted for a long time this afternoon.

Anyway, if you really want the streams I tried

http://mp3.live.tv-radio.com/fip/all/fiphautdebit.mp3
http://mp3.live.tv-radio.com/franceculture/all/franceculturehautdebit.mp3

Once again, the problem is not to find out what went wrong this afternoon for those streams, I don't really care, and it won't really help.

The fact is that streaming is poorly handled by Squeezeboxes, and many many people have been complaining for several years about that.
Rebuffering problems occur in various situations, and people are usually given very specific workaround for specific cases, or simply wait for stream problems to be fixed by the sender.

Today I could check for several hours, a very poor behavior regarding rebuffering, very specific to Squeezeboxes.
I am convinced there is something wrong in the way Squeezeboxes handle streams.
(In the same way there was something wrong with dropped streams in http://bugs.slimdevices.com/show_bug.cgi?id=3161 )
It is not the first time, but it was big enough and lasted long enough, so I had time to try several players, and cannot doubt there is a problem specific to squeezeboxes.

gerph
2012-01-02, 14:03
Well you gave a tremendous amount of technical explanations, very interesting for technical guys and developers.
The problem is not to explain to squeezeboxes users what is the theory of streaming and protocols.
I can easily understand that stuff, but the point is not to explain "WHY" LMS behavior is not user friendly in this particular case (users don't really care), but to understand that there "IS" a problem with squeezeboxes and rebuffering (at least users can hope the problem may be handled, if it is at least acknowledged).

My long explanation was to attempt to explain that you statements belied that fact that you did not understand 'that stuff' - stating that "The problem is not the size of the buffer, ... This is a well known problem for streaming software developpers." was not correct, at least according to my understanding and did not match with the explanation that I gave.

Similarly your suggestion that /corrupt/ streams be the cause of rebuffering certainly doesn't match with my own experience with either Squeezebox or developing streaming software.


Rebuffering has always been a big problem with squeezeboxes.

I am not "suggesting" anything.
This afternoon, I experienced for several hours a technical problem on a radio stream I listen almost every day, usually without problems.

It gave me time enough to check that this problem

1/ made the stream awfully unlistenable with Squeezebox.
2/ was not such a big problem with every other mean I tried to listen to it.

So that Squeezebox "IS" the problem there, because it cannot handle faults easily handled by other systems.

My question was not really to find the reason for this problem, but to know if there is some testing done as far as LMS reliability against poor streams is concerned.

If you don't want to find the solution and just want to know the detail of Logitech's internal QA... you're asking the wrong people. Speak to Logitech - I would suggest that they do have test suites and that they use them regularly. I'm sure that I saw a page detailing the many builds and tests that they ran, but cannot find it now. As you're interested in the tests being run, I'd also suggest you have a look at http://wiki.slimdevices.com/index.php/AudioTests which might be a little more enlightening.


Most people having rebuffering problems with squeezeboxes usually get advice suggesting that this is more or less normal, and that it is everything but software "bug" or let's say "user highly unfriendly behavior".

Today I unquestionably checked that LMS Squeezebox Touch has a big problem with a "poor" stream, while popular softwares do not.

The first thing to fix this kind of problem, is not to ask people to provide a testcase they cannot provide, but to start to have some in-house testcase generating "poor" streams , and check against those.

I wonder if this is done at Logitech's, because the behavior I experienced today seems to me a common problem, though usually not that dramatic, which appear again and again on various occasions.

The *first* thing to address this kind of problem is to check the common causes. Eliminate the things which are commonly a problem, however stupid they might seem. Otherwise you risk charging down a route which is not helpful. Assume that the company performs regular QA, and that you're not in the smaller group that get hit by the less common problems, and rule these out these. As part of that process, trying the things that are suggested seems sensible, and providing the appropriate information would be helpful.

I saw that a couple of people suggested that you change the buffer size, and asked if you'd tried that. You haven't said that you had tried that, just repeated that you had bad behaviour and that you didn't want to wait for the period that the rebuffering takes. As I hope I've explained in my somewhat dull post previously, the rebuffering period smooths out the data received by the system.

Similarly, a couple of people have suggested (as have I) that knowing what the station is and therefore the protocol in use would help to identify the problem. Other things to find out might include where you are, a record of the traceroute between yourself and the source station, and a ping record over the problematic period might all help.

But, if you're not interested in people helping identify the problem but just want to know what Logitech's internal processes are... well... good luck with that.

toby10
2012-01-02, 14:11
Yeah, neither will play at all for me on WinAmp or LMS. Might be GeoIP restricted.

nicolas75
2012-01-02, 14:20
Similarly your suggestion that /corrupt/ streams be the cause of rebuffering certainly doesn't match with my own experience with either Squeezebox or developing streaming software.

- The stream was poor I am positive about that.
- I had several seconds rebuffering, stopping replay, at least every minute.

My experience of software developping (streaming or not) is that poor data leading to bad user experience, can be called a "cause".
Deeper understanding of what is wrong may arise deeper effects or "causes", but I still call the poor data a "cause".
(Unless you say that they are not related, and that I would have experienced rebuffering with perfect stream anyway, and that rebuffering magically stopped by chance when stream finally got fine again).




If you don't want to find the solution and just want to know the detail of Logitech's internal QA... you're asking the wrong people.
...
But, if you're not interested in people helping identify the problem but just want to know what Logitech's internal processes are... well... good luck with that.

As I said in my previous post, my question is not to find out what went wrong this afternoon for those streams, I don't really care, and it won't really help.

You may find it useless and hopeless, but I don't completely agree.

It seems to me that in the last monthes, there were more and more users on this forum who don't buy anymore the geek statement that products are fine, and users don't know how to use them.

It is not completely useless to me.

nicolas75
2012-01-02, 14:23
Yeah, neither will play at all for me on WinAmp or LMS. Might be GeoIP restricted.

I don't think so.
The server is probably down, I cannot access them now. they really have problems today.

mike_zandvliet
2012-04-18, 22:00
I am experiencing the same problems with 7.7.1 and 7.7.2, against a SqueezeBox2. A lot of radio streams I am using are cutting out frequently - every few minutes. I don't think it's a local problem, as I have a good wifi and good ISP connectivity.

I've listened to the same stations in the past (several months ago) and had no real issues - maybe one dropout every 3 or 4 days at most. That's understandable - but not if it's every few minutes.

I've increased the buffer time to 30 seconds - but it didn't seem to help.

For now I've had to stop listening to radio steams and just go with local music.

Cheers,
Mike

toby10
2012-04-19, 03:33
Mike,
Try connecting the player to MySB.com and play those same stations. Is the result the same drop outs?

nicolas75
2012-04-23, 01:46
I am experiencing the same problems with 7.7.1 and 7.7.2, against a SqueezeBox2. A lot of radio streams I am using are cutting out frequently - every few minutes. I don't think it's a local problem, as I have a good wifi and good ISP connectivity.

I've listened to the same stations in the past (several months ago) and had no real issues - maybe one dropout every 3 or 4 days at most. That's understandable - but not if it's every few minutes.

I've increased the buffer time to 30 seconds - but it didn't seem to help.

For now I've had to stop listening to radio steams and just go with local music.

Cheers,
Mike


Nothing has changed for me either.
When the stream is bad I get several seconds rebuffering with the Touch.
When it happens, I switch to whatever other software on the PC (usually Foobar or MediaMonkey), and everything is fine.

bpa
2012-04-23, 02:49
Hav you tried enabling LMS "proxied streaming" for the problemplayers ?

This requires the player to be connect to a local LMS. Web UI Settings/Player/Audio - set MP3 streaming to "Proxied streaming". This is a per player setting.

The radio stream will first be handled by LMS server and then sent onto to player. It is similar to when when two players are synced with a local LMS.

Yves K
2012-04-25, 17:46
It's an interesting topic, one I know from other buffers, namely read/write buffers in CD/DVD equipment.

There is no magic: if there are gaps in the REALTIME stream, you can either acknowledge it or muddy the waters. In clear terms, either you hear the dropouts or you hear the dithering/interpolation done by the equipment that is trying hard as hell to provide "something" to the listener. Nicolas75 prefers to hear the interpolated data, accepting the lower quality, instead of hearing dropouts. Most people would do, too. But at the same time, the same people also want the highest quality output in normal conditions. And that is a design contradiction for which manufacturers have to make a conscious design choice:
Choice 1: favor the highest possible quality output
Choice 2: favor the best overall behaviour.

For choice 1, you take for granted that your input is of good quality and your equipment is then there to translate that input into the best possible output quality, possily at a ridiculously high cost. Typical example: most high-end expensive hi-fi equipment including valve amplifiers, speakers and speaker cables (!), interconnect cables, CD players, fancy DAC's...
For choice 2, you assume that the input can be wide-ranging and your equipment is then there to find the best way to produce an overall good output (at a reasonale cost). Typical example: TV sets, mainstream CD players

So, it looks like Mr Logitech has opted more for a hi-fi approach to the SBTouch, which implies that the device is going to behave poorly with poor inputs in order to favor superior results for decent inputs. It is not realisticly possible to design a one-size fits all. For CD players, the best quality is obtained by the devices that have minimal error recovery! All the design effort is put on the engineering of the best possible read capability on the first pass. For a CD with errors, the result is atrocious but for the 99 other CD's out of 100, the result is exquisite. It' a design choice to assume that most CD's are OK, and equipments are designed and tested against their intended capabilities. Personnally, I have a TP, 2 SBTouch and Slim Device. I avoid a poor quality stream because I cannot stand the result, it gets on my nerves, but in fact I enjoy them a lot because I find literally thousands (very acceptable) quality streams and podcasts...

Voila.


PS: I really liked the post from Gerph but for one quirk: with REALTIME streaming, if you loose information for x amount of time, you cannot get that back over time in your buffer. Anything which is not present time, is strictly past and cannot be called back. If the dropout takes 1 second, your 3 second buffer will be reduced to a 2 second buffer until the next dropout, eventually until the buffer runs empty at which time it will rebuffer 3 second (during which your hear nothing). That's the hard law of real-time streaming. Believe me, I can tell you a lot about buffer underruns that plagued so many CD-writers a few years ago...

nicolas75
2012-04-30, 03:09
...
So, it looks like Mr Logitech has opted more for a hi-fi approach to the SBTouch, which implies that the device is going to behave poorly with poor inputs in order to favor superior results for decent inputs.
...

From what I experience, I disagree.
Listening with other software, it is clear that dropouts last usually less than one second.
How could this justify 5 to 10 seconds complete and abrupt silence ?

There is no sound quality problem before and after the dropout (I have high end gear)

In my opinion the explanation is more the same than for Touch internal server clock loosing several seconds per month.
Nobody really care about fixing it, and this wrong behaviour was probably never carefully tested against poor streams generated on purpose.

Poor streams with short dropouts, generated on purpose, are the only way to check if what we experience is a bug or not.
More than that, it should be part of basic tests performed before version release.

bpa
2012-04-30, 03:19
Have you tried the "proxied" streaming mode I suggested ?

nicolas75
2012-05-02, 15:00
Have you tried the "proxied" streaming mode I suggested ?

Most of the time I am using TinySBS (and sometimes mysqueezebox.com) for streaming.
I only use LMS through MonkeySqueeze for local flac library, not for streaming.
So strictly speaking, I never use LMS (only as a bridge to interface MonkeySqueeze and Squeezebox Touch)
Library management for local library is (in my opinion and for my use) far less user friendly compared to popular music softwares, and useless for streaming.

Have you tested Squeezeboxes against streams with short dropouts, and compared agaisnt other music software or music systems ?

bpa
2012-05-02, 16:59
It is still worthwhile testing the using the LMS "proxied " settng enabled. If it fixes the problem then the issue will be identified.

Back in 6.5.x I did some testing on this sort of issue relating to "lumpy" streams which tended to deliver data in bursts. I found that PC based players could end up buffering far more data compared to SB players. PC players acked TCP packets as soon as they were received and so could build up a v. large amount of data ready to be played. SB player used to buffer only up to the TCP window size and packets would only be acked when they were decoded ready for playing. The only siutation where PC and hardware players behaved similarly was when playing "live" stream as the station could only audio data to the PC player as soon as it was available.


Have you tested Squeezeboxes against streams with short dropouts, and compared agaisnt other music software or music systems ?
Not sure what you mean by "short drop outs" - only in "Live" stream did I ever find gaps in audio stream as the station resyncs the broadcasted stream to make up for network congestion to ensure internet radio stream matches closely the actual broadcasted FM signal - in this case no TCP packets are lost but there are audio gaps.

nicolas75
2012-05-03, 11:01
It is still worthwhile testing the using the LMS "proxied " settng enabled. If it fixes the problem then the issue will be identified.

Not for me since I will not use LMS anyway.
Honestly I don't feel like debugging a software I will not use, when it is so easy for anyone to check Squeezeboxes behavior against almost any popular music software, and actually hear the problem.
I have done it enough, and this rebuffering problem was already there back in 2008 with Squeezebox Classic (4 years ago ...)
Software development is my job, I don't see it as a funny occupation or a hobby.
My Touch is not listenable with poor streams.
When I experience poor streams (it does not happen very often), I don't feel like making tests that should have been performed before LMS and firmware release.
I switch the Touch off, use the computer and Foobar or Mediamonkey through a small USB DAC, and everything is fine for me.
If Logitech decide to correct this bug, they will have to do those tests anyway, no matter if I try the proxy thing or not.


Not sure what you mean by "short drop outs" - only in "Live" stream did I ever find gaps in audio stream as the station resyncs the broadcasted stream to make up for network congestion to ensure internet radio stream matches closely the actual broadcasted FM signal - in this case no TCP packets are lost but there are audio gaps.

When you experience rebuffering with those streams, try listening to them with Foobar or MediaMonkey at the same time.
There is no way you can miss the problem, if you test when rebuffering occurs for live streams.

I remember endless discussions about Touch clock issue, with bunch of people trying to find strange explanations without testing.
When we finally got them actually test TinySBS clock for a few days, in the end they had to acknowledge the bug, a bug was opened in Bugzilla, and .... ,
http://bugs.slimdevices.com/show_bug.cgi?id=17164
It is still opened with 23 votes ..., still not corrected ..., and I honestly doubt it will ever be.

dwc
2012-09-06, 13:09
Listening to live audio streams is a daily practice for us. It's what we turn on in the kitchen when we make morning coffee.

I almost never had radio stream buffering issues with server version 5.x.

With 7.7.2 - the issue is so bad it is unlistenable. The station (kalw 91.7 for example) rebuffers so frequently you can't follow the content.

i wonder what changed in live streaming and buffering between those versions. it was truly better i the previous version.

toby10
2012-09-07, 01:52
Listening to live audio streams is a daily practice for us. It's what we turn on in the kitchen when we make morning coffee.

I almost never had radio stream buffering issues with server version 5.x.

With 7.7.2 - the issue is so bad it is unlistenable. The station (kalw 91.7 for example) rebuffers so frequently you can't follow the content.

i wonder what changed in live streaming and buffering between those versions. it was truly better i the previous version.

Computer? OS? Player? Tried connecting directly to MySB.com for comparison?

That station played fine for me on 7.7.2 for over an hour, not a single rebuffer or hiccup, and over two WiFi hops.

5 year old WinXP laptop eunning LMS 7.7.2 over WiFi to a WiFi Radio

dwc
2012-09-07, 09:16
Computer? OS? Player? Tried connecting directly to MySB.com for comparison?

That station played fine for me on 7.7.2 for over an hour, not a single rebuffer or hiccup, and over two WiFi hops.

5 year old WinXP laptop eunning LMS 7.7.2 over WiFi to a WiFi Radio

First off, the architecture was identical pre and post server upgrade. That's why I didn't initially go into detail on my architecture, as it worked fine prior to server upgrading. That being said I appreciate any help and if there's something I can do via config to fix the issue I will happily do it.

Computer:
There have been two servers, the first one had a mobo failure, and so I switched boxes. Both old and new servers suffer the buffering issue on the radio streams.

Current server (likewise an older box):
WinXP SP 3
Pentium 4 2 GHZ
1 GB ram

Player in question: Boom

Yes - the stream buffers via mysqueezebox as well as via my local server.

No wifi hops, all wired. (Never any buffering issues with local music)

internet: Dual bonded DSL lines, sufficient to stream Netflix in HD. I get about 50ms ping, 4.6-5.0 Mbps download speed.

toby10
2012-09-07, 14:03
Since you mentioned which player you are using I've been streaming KALW on a WiFi Boom with the same firmware level as yours. No issues.
Dunno what to tell you. :(

bpa
2012-09-07, 14:18
Is the stream you are playing MP3 and WMA and playing direct to player or is it being processed by LMS (e.g. sync, bit rate limiting, transcoding) before going to player ?
What is the Radio station buffer setting ?
Have you tried "proxied" streaming ? if it improves thhings then it can indicate the origin of the problem
Has your ISP introduced some form of traffic management ?

toby10
2012-09-08, 02:45
KALW is 64k mp3, user says same issues when playing from MySB (so guessing not LMS settings issue), user says can stream HD movies (so guessing not ISP limits).

Interesting tidbit: Left KALW streaming all night, still playing this morning. But when I now go to check the More Info from the NP screen (to verify my memory of 64k mp3) I get an error "Cannot request non-HTTP URL". Possibly a clue?

bpa
2012-09-08, 03:57
KALW is 64k mp3, user says same issues when playing from MySB (so guessing not LMS settings issue), user says can stream HD movies (so guessing not ISP limits).

AFAICT KALW is available in WMA as well as MP3.

This is my opinion and just one possible explanation. When SB player is playing direct the TCP window is not moved (i.e. packet acked) until it is ready to be decoded whereas a HD movies streaming to a PC will move TCP windows (i.e. ack every packet) into PC memopry well before the playing applicaiton is ready. This means SB players have more short burst and when window edge is moved ISP has to react quickly (i./e pass ack back to station) to ensure packets are sent quickly. If this doesn't happen quick enough you can get rebuffering. The fast the playing stream the more noticeable the effect because with fixed size buffer there is less time. With HD playing there is enough data acked and buffered in PC memory that a slight delay in getting more data does not affect playback.

If user tries LMS proxied streaming and playtback imporves then the above is one of the reasons for the problem.

ISP can do traffic management based on source and so data from HD streaming sources may get priority over "ordinary" traffic.