Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 36
  1. #21
    Senior Member toby10's Avatar
    Join Date
    Jul 2007
    Location
    USA (home of the bottomless credit card)
    Posts
    8,443
    Mike,
    Try connecting the player to MySB.com and play those same stations. Is the result the same drop outs?

  2. #22
    Senior Member
    Join Date
    Mar 2008
    Posts
    396
    Quote Originally Posted by mike_zandvliet View Post
    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.

  3. #23
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    11,770
    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.

  4. #24
    Junior Member
    Join Date
    Feb 2009
    Posts
    4
    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...

  5. #25
    Senior Member
    Join Date
    Mar 2008
    Posts
    396
    Quote Originally Posted by Yves K View Post
    ...
    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.

  6. #26
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    11,770
    Have you tried the "proxied" streaming mode I suggested ?

  7. #27
    Senior Member
    Join Date
    Mar 2008
    Posts
    396
    Quote Originally Posted by bpa View Post
    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 ?
    Last edited by nicolas75; 2012-05-02 at 15:03.

  8. #28
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    11,770
    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.
    Last edited by bpa; 2012-05-02 at 17:03.

  9. #29
    Senior Member
    Join Date
    Mar 2008
    Posts
    396
    Quote Originally Posted by bpa View Post
    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.

    Quote Originally Posted by bpa View Post
    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.
    Last edited by nicolas75; 2012-05-03 at 11:24.

  10. #30
    Senior Member dwc's Avatar
    Join Date
    Oct 2005
    Posts
    353
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •