PDA

View Full Version : quick summary of 6.0 changes?



Brian Abbott, ACA Systems
2005-01-04, 11:15
I seem to recall that the 'official' position on streaming FLAC/WAV is that
'it might work if the connection is good, but if not you can always attach a
8011.g access point to the SP's rj45 ...'

Robin Bowes wrote:
>
> A stereo wav file sampled at 44.1kHz (i.e. CD quality) will consist
> of 44,100 pairs of 16-bit samples for every second of music, so the
> bit-rate required is 44,100 x 2 x 16 = 1.4Mb/s.
>
> Both the wired and wireless interfaces of the Squeezebox have more
> than enough capacity to cope with this. 11g may be a more robust
> protocol or have better range but it wouldn't make any difference in
> terms of bandwidth.
>
> R.
>
>

ron thigpen
2005-01-04, 13:09
Brian Abbott, ACA Systems wrote:
> I seem to recall that the 'official' position on streaming FLAC/WAV is that
> 'it might work if the connection is good, but if not you can always attach a
> 8011.g access point to the SP's rj45 ...'

I might paraphrase my memory of this as: "should the performance
implications, imagined or otherwise, of running a mixed 802.11b/g
network be unacceptable to you, the official position on how you might
get to a pure G wireless network is to attach an 802.11g access point to
the SB's RJ45. Depending on the cause, this may or may not improve the
playback issues you are experiencing with your SB."

I am certain that HW items such as in-box 802.11g, FLAC decode and much
larger buffer must be on the wishlist for the next design revision.

That's not to say we shouldn't improve the server in the meantime.

--rt

Jack Coates
2005-01-04, 13:29
ron thigpen wrote:
....

>
> I am certain that HW items such as in-box 802.11g, FLAC decode and much
> larger buffer must be on the wishlist for the next design revision.
>

Don't forget that a larger buffer can create as many problems as it
solves. I for one wouldn't like any delay between hitting a button and
hearing a response.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

ron thigpen
2005-01-04, 13:41
Jack Coates wrote:

> Don't forget that a larger buffer can create as many problems as it
> solves. I for one wouldn't like any delay between hitting a button and
> hearing a response.

Don't forget that you don't strictly need to fill a buffer before you
begin consuming it's contents. If the bits can be delivered faster than
realtime playback requires, the fill can continue after playback begins.
Granted, you wouldn't get the benefit of deep buffering until some
small period into the track, but you'd gain a more responsive UI. All
of this may require more complex buffer management algorithms, but that
may be exactly what Sean has been hacking lately. We'll know when we know.

--rt