PDA

View Full Version : Native FLAC?



Daryle A. Tilroe
2004-03-03, 09:25
Neil Davidson wrote:
> my understanding is that you will never see this, just like you will never
> see native OGG or ACC decoding in the SB. The chip in the SB is a dedicated
> MP3 decoder which can also stream WAV and PCM. There is no facility to add
> different codec support to the Squeezebox.

Really? Perhaps this is old information for the SLIMP3? Can someone from
slimdevices confirm this? I had information that suggested additional codecs
could be supported within the limitation of processing power and licensing.
Time to pop the lid! :-) I would be somewhat disappointed if native FLAC
is definitely not possible.

> What is your reason for wanting this? I know it would reduce the bandwidth
> of a loss less stream, but even with wireless, 170KB/sec isn't a lot.

It is about a factor of five difference between uncompressed WAV/PCM and
typical MP3 streams. In other words five times the bandwidth and 1/5
the buffering. 802.11b tends to have a practical max of around 5Mb/s
and you are pushing things with more than one uncompressed WAV/PCM stream
at 1.5Mb/s and any other traffic. Further, in my limited practical
experience, things get flaky with WAV/PCM and a signal strength lower than
40%. Drop outs and play stoppages that require rebooting the SqueezeBox.
I am going to probably have to hardwire the SB to get clean 10Mb/s to
it and eliminate bandwidth/signal problems from the equation. There
may also be some problems recovering the streaming from the server when
things get interrupted or there just may be a few bugs in the FLAC
decoding and streaming when hopping around to different songs.

What it boils down to is that, with wireless at least, there is little
margin for error or signal problems when streaming uncompressed WAV/PCM.
If native FLAC is not to be than permanent hardwiring will likely be a
must.

--
Daryle A. Tilroe

dean
2004-03-03, 09:32
Client-side FLAC decoding may be possible in Squeezebox, Sean's
investigating it now.

Client-side decoding of other codecs may also be possible, but would be
farther out in the future.

Additional client-side codec support on SLIMP3 isn't possible. Sorry.

-dean

On Mar 3, 2004, at 8:25 AM, Daryle A. Tilroe wrote:

> Neil Davidson wrote:
>> my understanding is that you will never see this, just like you will
>> never
>> see native OGG or ACC decoding in the SB. The chip in the SB is a
>> dedicated
>> MP3 decoder which can also stream WAV and PCM. There is no facility
>> to add
>> different codec support to the Squeezebox.
>
> Really? Perhaps this is old information for the SLIMP3? Can someone
> from
> slimdevices confirm this? I had information that suggested additional
> codecs
> could be supported within the limitation of processing power and
> licensing.
> Time to pop the lid! :-) I would be somewhat disappointed if native
> FLAC
> is definitely not possible.
>
>> What is your reason for wanting this? I know it would reduce the
>> bandwidth
>> of a loss less stream, but even with wireless, 170KB/sec isn't a lot.
>
> It is about a factor of five difference between uncompressed WAV/PCM
> and
> typical MP3 streams. In other words five times the bandwidth and 1/5
> the buffering. 802.11b tends to have a practical max of around 5Mb/s
> and you are pushing things with more than one uncompressed WAV/PCM
> stream
> at 1.5Mb/s and any other traffic. Further, in my limited practical
> experience, things get flaky with WAV/PCM and a signal strength lower
> than
> 40%. Drop outs and play stoppages that require rebooting the
> SqueezeBox.
> I am going to probably have to hardwire the SB to get clean 10Mb/s to
> it and eliminate bandwidth/signal problems from the equation. There
> may also be some problems recovering the streaming from the server when
> things get interrupted or there just may be a few bugs in the FLAC
> decoding and streaming when hopping around to different songs.
>
> What it boils down to is that, with wireless at least, there is little
> margin for error or signal problems when streaming uncompressed
> WAV/PCM.
> If native FLAC is not to be than permanent hardwiring will likely be a
> must.
>
> --
> Daryle A. Tilroe
>
>

Kevin O. Lepard
2004-03-03, 09:35
>Client-side FLAC decoding may be possible in Squeezebox, Sean's
>investigating it now.

Oh, sure. Go and do something to make me want to re-encode my entire
CD collection. :-)

Kevin
--
Kevin O. Lepard
lepard.kevin (AT) fireserve (DOT) net

Happiness is being 100% Microsoft free.

Pat Farrell
2004-03-03, 09:49
At 11:25 AM 3/3/2004, Daryle A. Tilroe wrote:
>>What is your reason for wanting this? I know it would reduce the bandwidth
>>of a loss less stream, but even with wireless, 170KB/sec isn't a lot.
>
>It is about a factor of five difference between uncompressed WAV/PCM and
>typical MP3 streams. In other words five times the bandwidth and 1/5
>the buffering.

True, but FLAC is lossless and typically gets more like 50%
I find that for many tracks, I only get 40% reduction (to 60% of original).

I'm not up to speed on WiFi engineering, but on wired Ethernet, your
comment about 10% being a much more realistic capacity is
a good rule of thumb. You can get higher on special occasions,
special setups, but in general, you don't get all the theoritical
speed. See all the TokenRing is better arguments from 1987

Native Flac would be a cool thing, but I don't think it would be
all that much of "the next great thing".

On my firmware wishlist, I'd put bigger buffers so the Sqbx can handle
short dropouts better way before native Flac, all IMHO, 'natch.

Pat

seanadams
2004-03-03, 10:04
>
> I'm not up to speed on WiFi engineering, but on wired Ethernet, your
> comment about 10% being a much more realistic capacity is
> a good rule of thumb.

All you need to do is time a large file transfer to see for yourself
that this "rule of thumb" is utter nonsense. Ethernet runs at exactly
10, 100, or 1000 mbps. Subtract TCP/IP headers, ethernet frame headers,
preamble and you're still at well over 95%. Real-world throughput on
ethernet could well be limited by slower applications, operating
systems, and disk drives, but not the wire!

Pat Farrell
2004-03-03, 10:12
At 12:04 PM 3/3/2004, Sean Adams wrote:
>> I'm not up to speed on WiFi engineering, but on wired Ethernet, your
>> comment about 10% being a much more realistic capacity is
>> a good rule of thumb.
>
>All you need to do is time a large file transfer to see for yourself that
>this "rule of thumb" is utter nonsense. Ethernet runs at exactly 10, 100,
>or 1000 mbps. Subtract TCP/IP headers, ethernet frame headers, preamble
>and you're still at well over 95%. Real-world throughput on ethernet
>could well be limited by slower applications, operating systems, and disk
>drives, but not the wire!

The signaling runs at spec. Sure.

Ethernet uses CSMA/CD (Carrier Sense Multiple Access/Collision Detect)
If you are using a switch, then you don't have collisions.
If you are using a shared media, you first have to share the media
with the other stations, and second, have to back off for the
collision resolution (random wait time) to happen.
Ethernet does not allow two stations to talk at once.

Running real world at 95% is not typical.
That said, reducing the traffic volume by even 50% does wonders
for the overall throughput. The net transfer rate has a hockey stick
shaped curve, it gets really non-linear as the limit is reached.

Pat

Ron Thigpen
2004-03-03, 10:19
dean blackketter wrote:

> Client-side FLAC decoding may be possible in Squeezebox, Sean's
> investigating it now.

Client-side FLAC decoding would be terrific!

--rt

Richard Purdie
2004-03-03, 10:22
> At 12:04 PM 3/3/2004, Sean Adams wrote:
> >> I'm not up to speed on WiFi engineering, but on wired Ethernet, your
> >> comment about 10% being a much more realistic capacity is
> >> a good rule of thumb.
> >
> >All you need to do is time a large file transfer to see for yourself that
> >this "rule of thumb" is utter nonsense. Ethernet runs at exactly 10,
100,
> >or 1000 mbps. Subtract TCP/IP headers, ethernet frame headers, preamble
> >and you're still at well over 95%. Real-world throughput on ethernet
> >could well be limited by slower applications, operating systems, and disk
> >drives, but not the wire!
>
> Running real world at 95% is not typical.
> That said, reducing the traffic volume by even 50% does wonders
> for the overall throughput. The net transfer rate has a hockey stick
> shaped curve, it gets really non-linear as the limit is reached.

The 10% rule seems to date from the days of 10MBit coax style ethernet. On
that you only had half duplex, collisions were frequent and most networks
had a large number of stations all doing things at once. 10% was therefore a
good guide. Things have changed.

On modern home networks you have have a full duplex switch managing a small
number of stations which aren't likely to be using the network at once.
While 95% may be a touch optomistic, 70-80% isn't probably a bad rule of
thumb in the home enviornment.

Funnily enough I pulled out a major part of my old coax home network cable
just the other day...

RP

Bob Fish
2004-03-03, 10:36
> >
> > I'm not up to speed on WiFi engineering, but on wired Ethernet,
> > your comment about 10% being a much more realistic capacity is a
> > good rule of thumb.
>
> All you need to do is time a large file transfer to see for yourself
> that this "rule of thumb" is utter nonsense. Ethernet runs at exactly
> 10, 100, or 1000 mbps. Subtract TCP/IP headers, ethernet frame
> headers, preamble and you're still at well over 95%. Real-world
> throughput on ethernet could well be limited by slower applications,
> operating systems, and disk drives, but not the wire!

It seems you are confusing transfer speed with throughput. Bits are
modulated onto an ethernet wire at the stated rate (10/100).

However, throughput is a function of loading on the wire/network. If you
only have 1 machine, you get it all. IF you have many, performance drops
for everyone.

Back to the original post:
I did some experimentation with FLAC, Monkey, and WAVPACK about 2 years ago
and got nowhere near 50% compresson on a typical audiofile (usually 20-30%)
when using lossless compression. What's your secret? Maybe I need to try
again.
compression. H

seanadams
2004-03-03, 10:59
> It seems you are confusing transfer speed with throughput. Bits are
> modulated onto an ethernet wire at the stated rate (10/100).
>

No, I'm not. And you don't have to trust me because I work on ethernet
devices and TCP/IP stacks for a living. Just give it a try, and you
can discover what real-world ethernet throughput is empirically. Here's
my test:

Machine #1: 2.4G pentium, linux:

dd if=/dev/zero of=bigfile count=204800 # makes a 100MB file

Machine #2: Mac G4 1GHz

ftp machine1
get bigfile

I get 11.16MB/sec... that's 89 out of 100 mbps, with two switches and a
90 meter span in between, and no special tuning.

Also, try a few machines on a shared hub, doing a big transfer
simultaneously and you'll find it's still not nearly as bad as the
legends say.

Daryle A. Tilroe
2004-03-03, 12:04
Richard Purdie wrote:
>>At 12:04 PM 3/3/2004, Sean Adams wrote:
>>
>>>> I'm not up to speed on WiFi engineering, but on wired Ethernet, your
>>>> comment about 10% being a much more realistic capacity is
>>>> a good rule of thumb.
>>>
>>>All you need to do is time a large file transfer to see for yourself that
>>>this "rule of thumb" is utter nonsense. Ethernet runs at exactly 10,
>>
> 100,
>
>>>or 1000 mbps. Subtract TCP/IP headers, ethernet frame headers, preamble
>>>and you're still at well over 95%. Real-world throughput on ethernet
>>>could well be limited by slower applications, operating systems, and disk
>>>drives, but not the wire!
>>
>>Running real world at 95% is not typical.
>>That said, reducing the traffic volume by even 50% does wonders
>>for the overall throughput. The net transfer rate has a hockey stick
>>shaped curve, it gets really non-linear as the limit is reached.
>
>
> The 10% rule seems to date from the days of 10MBit coax style ethernet. On

If you look carefully I was not using a '10%' rule for 802.11b. I
said that in my experience you typically max out less than 50% of
rated 11Mb/s, i.e. 5Mb/s. This jives with slimdevices' FAQ:

http://www.slimdevices.com/su_faq.html#about-wirelessperformance

The '10%' rule I use would be estimating on 100Mb/s ethernet you
get about 10MB/s after overhead, etc.

--
Daryle A. Tilroe

Andrew W. Donoho
2004-03-03, 12:09
On Mar 3, 2004, at 10:32, dean blackketter wrote:

> Client-side FLAC decoding may be possible in Squeezebox, Sean's
> investigating it now.
>
> Client-side decoding of other codecs may also be possible, but would
> be farther out in the future.


I would put in a vote for client side AAC decoding before FLAC. Because
of iTunes/iPod market success, you have huge collection of AAC material
available to your installed and growing base of customers. There is a
GPL implementation of a decoder (FAAD2). I believe it is also available
for commercial license. The patent royalty issues are clear. My faad
binary is only 68kB in size. As I am sure everyone knows, chewing up
170 kB/s for WAV or AIFF streams out of 600 kB/s real available
bandwidth on 802.11b puts the reliability of the audio stream at risk.
If customers turn on WEP, it reduces the available bandwidth even more.
In my case, with 192 kbps AAC files, I would only use 10% of the above
bandwidth. For the same reason, I would also recommend that folks who
wish to use music formats that are expanded into WAV or AIFF should
consider the wired version of the SqueezeBox.

After AAC, if the market justifies it, I would consider WMA. Though
FLAC is probably more popular than WMA with your audiophile clientele.

Andrew

____________________________________
Andrew W. Donoho
awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

Daryle A. Tilroe
2004-03-03, 12:12
dean blackketter wrote:
> Client-side FLAC decoding may be possible in Squeezebox, Sean's
> investigating it now.
>
> Client-side decoding of other codecs may also be possible, but would be
> farther out in the future.
>
> Additional client-side codec support on SLIMP3 isn't possible. Sorry.
>
> -dean

Great!! That is what I had understood. So is it coming
soon enough that I don't need to bother running the ethernet?
Come on toss us a hint here. :-) This would also be a nice
solution in terms of encoding other WAV/PCM high quality source
material on the server into FLAC in real time for transmission
to the SqueezeBox.

I consider a 50% reduction in bandwidth (and double the buffer
time on the other end) a significant improvement for wireless;
particularly with multiple SqueezeBoxes.

--
Daryle A. Tilroe

Dan Sully
2004-03-03, 12:13
* Andrew W. Donoho <awd (AT) DDG (DOT) com> shaped the electrons to say...

>After AAC, if the market justifies it, I would consider WMA. Though
>FLAC is probably more popular than WMA with your audiophile clientele.

The problem with both of these is that they require more horsepower to
decode. FLAC is meant to be very trivial to decode in hardware, specifically
for embedded applications such as the Squeezebox.

-D
--
The floggings will continue until morale improves.

Daryle A. Tilroe
2004-03-03, 12:23
Andrew W. Donoho wrote:

> I would put in a vote for client side AAC decoding before FLAC. Because
> of iTunes/iPod market success, you have huge collection of AAC material
....
> After AAC, if the market justifies it, I would consider WMA. Though FLAC
> is probably more popular than WMA with your audiophile clientele.

I would disagree and I think you hit it there at the end. The
competitive advantage of the SqueezeBox is supporting uncompressed
(and hopefully soon losslessly compressed) streaming. If you
want an MP3 device than there are other solutions (Tivo, etc.).

AFAIK the SqueezeBox is the only compact appliance that you can
hookup and get the functionality and *quality* equivalent of a
300 (actually unlimited) CD changer. If you are talking lossy
then why not just transcode the AAC to MP3 for transmission?
If you choose a higher MP3 bitrate the transcoding artifacts
are probably not to bad. You are talking abour crippled music
in the first place, which I would never pay a dime for, but
that is a whole other argument! :-)

As a matter of fact, as someone already pointed out, a major
reason for FLAC could be considered the streaming bandwidth
improvement since storage is so cheap now. Of course right
now FLAC makes the difference between fitting my CD collection
on a pair of mirrored 200GB HDDs and not. That will change when
400GB drives come out in a a year or two.

--
Daryle A. Tilroe

seanadams
2004-03-03, 12:26
I've estimated CPU cost and I believe it should fit. The proof is in
the putting though and we'll know when it's done. There are also some
improvements that will be made to TCP which should improve performance
significantly when there's packet loss.

We're also investigating a lossless format of our own, CRAC, to be used
just for streaming, which should give very close to the compression
rates attained by FLAC, but at much lower CPU cost on both ends of the
link (FLAC is already pretty cheap, I should add).

Over the next month or so this next firmware update will be coming
together and I will have more updates.

On Mar 3, 2004, at 11:12 AM, Daryle A. Tilroe wrote:

> dean blackketter wrote:
>> Client-side FLAC decoding may be possible in Squeezebox, Sean's
>> investigating it now.
>> Client-side decoding of other codecs may also be possible, but would
>> be farther out in the future.
>> Additional client-side codec support on SLIMP3 isn't possible. Sorry.
>> -dean
>
> Great!! That is what I had understood. So is it coming
> soon enough that I don't need to bother running the ethernet?
> Come on toss us a hint here. :-) This would also be a nice
> solution in terms of encoding other WAV/PCM high quality source
> material on the server into FLAC in real time for transmission
> to the SqueezeBox.
>
> I consider a 50% reduction in bandwidth (and double the buffer
> time on the other end) a significant improvement for wireless;
> particularly with multiple SqueezeBoxes.
>
> --
> Daryle A. Tilroe
>
>

Andrew W. Donoho
2004-03-03, 12:33
On Mar 3, 2004, at 13:13, Dan Sully wrote:
> * Andrew W. Donoho <awd (AT) DDG (DOT) com> shaped the electrons to say...
>> After AAC, if the market justifies it, I would consider WMA. Though
>> FLAC is probably more popular than WMA with your audiophile
>> clientele.
>
> The problem with both of these is that they require more horsepower to
> decode. FLAC is meant to be very trivial to decode in hardware,
> specifically
> for embedded applications such as the Squeezebox.


There is always a tension between market and technical requirements. I
think SlimDevices has to balance catering to their early adopter market
with gaining market success by embracing emerging standards, like AAC,
more quickly than the "big" CE vendors. Frankly, the SqueezeBox has the
margin in it to compete with the big boys if SlimDevices uses their
inherent flexibility for market advantage. Also, reflecting the glow of
iPod's success by using "iPod native" AAC may have more marketing bang
than you might think to enhance sales. The real challenge is to get DRM
AAC into the SqueezeBox or get the SqueezeBox as one of the defined
iTunes Music Store music sharing systems. That would bump up sales even
more than the already excellent SlimDevices-iTunes integration. It
would also make the music industry folks happy to have the DRM stripped
in a machine that has no permanent storage for music.

Andrew

____________________________________
Andrew W. Donoho
awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

Peter Speck
2004-03-03, 12:39
On 3/3-2004, at 20:12, Daryle A. Tilroe wrote:

> dean blackketter wrote:
>> Client-side FLAC decoding may be possible in Squeezebox, Sean's
>> investigating it now.
> [...]
> I consider a 50% reduction in bandwidth (and double the buffer
> time on the other end) a significant improvement for wireless;
> particularly with multiple SqueezeBoxes.

I'm using uncompressed AIFF (aka PCM), and 802.11b with 128 bit WEP.

During night, it works without problems. During daytime, I have some
1-2 seconds dropouts. Looking at bufferfullness in the display gives me
the impression that twice the amount of buffer in the Squeezebox would
avoid 80% of the dropouts.

----
- Peter Speck

Pat Farrell
2004-03-03, 12:51
At 02:26 PM 3/3/2004, Sean Adams wrote:
>e're also investigating a lossless format of our own, CRAC, to be used
>just for streaming, which should give very close to the compression rates
>attained by FLAC, but at much lower CPU cost on both ends of the link
>(FLAC is already pretty cheap, I should add).

The world does not need another compression format, it needs more
people to know how to use the existing ones, and why they are cool.
Altho an OpenSouce one, as opposed to MLP, would not necessarily be
a bad thing.

As you say, Flac was designed to be cheap to decode. Even if you
do tons better there, it makes no difference. Compressing
is a one time, or once every change of format (years) event.
Plus Intel and AMD keep making faster and faster CPUs that
we can't use up.

So it seems to me that you are over optimizing.

I'd especially be concerned if adding CRAC and supporting it forever
meant you had to do less support for high-width, high rate formats like DVD-A
Just my two cents.

Pat

seanadams
2004-03-03, 13:03
I agree that CRAC, aka YALC (yet another lossless codec) would not be
preferable to FLAC *in general* I mean, for non-squeezebox uses.
However, keep in mind the anticipated application for this - many
codecs can be improved/customized/optimized given specific
architectures/applications, and FLAC is no exception. And since such a
new codec would be lossless and intended ONLY to communicate between
server<->squeezebox (but open, of course), the usual codec concerns
about quality and interoperability simply do not apply. Files would
still be stored in standard formats, no doubt.

Anyway it's just an idea we've kicked around. No code has been written
yet and FLAC is a higher priority.

On Mar 3, 2004, at 11:51 AM, Pat Farrell wrote:

> At 02:26 PM 3/3/2004, Sean Adams wrote:
>
> e're also investigating a lossless format of our own, CRAC, to be used
> just for streaming, which should give very close to the compression
> rates attained by FLAC, but at much lower CPU cost on both ends of the
> link (FLAC is already pretty cheap, I should add).
>
> The world does not need another compression format, it needs more
> people to know how to use the existing ones, and why they are cool.
> Altho an OpenSouce one, as opposed to MLP, would not necessarily be
> a bad thing.
>
> As you say, Flac was designed to be cheap to decode. Even if you
> do tons better there, it makes no difference. Compressing
> is a one time, or once every change of format (years) event.
> Plus Intel and AMD keep making faster and faster CPUs that
> we can't use up.
>
> So it seems to me that you are over optimizing.
>
> I'd especially be concerned if adding CRAC and supporting it forever
> meant you had to do less support for high-width, high rate formats
> like DVD-A
> Just my two cents.
>
> Pat
>

Daryle A. Tilroe
2004-03-03, 13:33
Pat Farrell wrote:
> At 02:26 PM 3/3/2004, Sean Adams wrote:
>
>> e're also investigating a lossless format of our own, CRAC, to be used
>> just for streaming, which should give very close to the compression
>> rates attained by FLAC, but at much lower CPU cost on both ends of the
>> link (FLAC is already pretty cheap, I should add).
>
>
> The world does not need another compression format, it needs more
> people to know how to use the existing ones, and why they are cool.
> Altho an OpenSouce one, as opposed to MLP, would not necessarily be
> a bad thing.
>
> As you say, Flac was designed to be cheap to decode. Even if you
> do tons better there, it makes no difference. Compressing
> is a one time, or once every change of format (years) event.
> Plus Intel and AMD keep making faster and faster CPUs that
> we can't use up.
>
> So it seems to me that you are over optimizing.

I second this notion. FLAC was designed for low powered
hardware on the decode side. That's why I threw my lot
in with them; that and open source goodness. I am hoping
FLAC is the new MP3 for those of us who like to hear all of
the music (I know 24/96, etc. would be even better but 16/44
is a pretty good standard for 99.99% of us, particularly
when you consider the number of people/companies who seem to
be dragging us back to FM radio quality MP3s).

Given the diminishing returns and considering how FLAC seems
to be almost the best:

http://flac.sourceforge.net/comparison.html

I think efforts towards another format would be better spent
somewhere else, particularly since your hardware is only
going to get faster; ie. if FLAC does it for you now there
is no point.

--
Daryle A. Tilroe

Ben Sandee
2004-03-03, 13:52
Daryle A. Tilroe wrote:

> Pat Farrell wrote:
>
>> At 02:26 PM 3/3/2004, Sean Adams wrote:
>>
>>> e're also investigating a lossless format of our own, CRAC, to be
>>> used just for streaming, which should give very close to the
>>> compression rates attained by FLAC, but at much lower CPU cost on
>>> both ends of the link (FLAC is already pretty cheap, I should add).
>>
>>
>> The world does not need another compression format, it needs more
>> people to know how to use the existing ones, and why they are cool.
>> Altho an OpenSouce one, as opposed to MLP, would not necessarily be
>> a bad thing.
>
> I think efforts towards another format would be better spent
> somewhere else, particularly since your hardware is only
> going to get faster; ie. if FLAC does it for you now there
> is no point.
>
I think the point both of you are missing is that the new format is
designed for real-time encoding by slimserver before sending to squeeze,
not for archiving purposes like FLAC. These are different design
goals. FLAC is quite cpu intensive on the encoding side so transcoding
to FLAC when network bandwidth is at a premium may not be possible.

Ben

Daryle A. Tilroe
2004-03-03, 14:13
Ben Sandee wrote:
> I think the point both of you are missing is that the new format is
> designed for real-time encoding by slimserver before sending to squeeze,
> not for archiving purposes like FLAC. These are different design
> goals. FLAC is quite cpu intensive on the encoding side so transcoding
> to FLAC when network bandwidth is at a premium may not be possible.

I don't think we are quite missing the point. FLAC is quite cpu
intensive on the encoding only in comparison to the decoding. If
you look at that chart you will see that at -3 it encodes at ~13%
of real time or in other words at almost 8x real-time. And that is
on a *PII-333*; about 1/10 of the computing power on a some desktops
right now. This to is only going to become less relevant as well
as CPU horsepower gets better. If silmdevices wants a lossless
real-time encoding format for communication they would do well to
consider FLAC rather than reinventing the wheel.

On a related note I actually heard about the SqueezeBox from the
link on the FLAC site.

--
Daryle A. Tilroe

Pat Farrell
2004-03-03, 14:16
At 03:52 PM 3/3/2004, Ben Sandee wrote:
>>Pat Farrell wrote:
>>think the point both of you are missing is that the new format is
>>designed for real-time encoding by slimserver before sending to squeeze,
>>not for archiving purposes like FLAC. These are different design
>>goals. FLAC is quite cpu intensive on the encoding side so transcoding
>>to FLAC when network bandwidth is at a premium may not be possible.

No, I didn't miss that.
I just don't see much point in it.
You are, of course, correct in that flac is way intensive to encode.

I don't want a new streaming format. If I want to play
my existing songs, I've encoded/compressed them already.
If I want to play some radio station, just play it as it comes in
or transcode as needed.

I may be missing something, it has happened in the past, but
a new streaming format does nothing for me over
having the Sqbx handle Flac or MLP or other lossless decoding
on the fly.

I think a bigger potential problem is all the wireless phones
and multiple laptops compeating for the WiFi bandwidth.

Plus, WiFi G has completely overtaken 802.11b, and so it will
soon be obsolete. Such is the computer industry.

Pat

Richard Purdie
2004-03-03, 14:29
> > The 10% rule seems to date from the days of 10MBit coax style ethernet.
On
>
> If you look carefully I was not using a '10%' rule for 802.11b. I
> said that in my experience you typically max out less than 50% of
> rated 11Mb/s, i.e. 5Mb/s. This jives with slimdevices' FAQ:
>
> http://www.slimdevices.com/su_faq.html#about-wirelessperformance
>
> The '10%' rule I use would be estimating on 100Mb/s ethernet you
> get about 10MB/s after overhead, etc.

What I said is that the 10% rule dates from the days of coax Ethernet. It is
no longer valid, especially in a home 100Mb/s switched Ethernet environment.
As Sean says - try it and see.

I made no mention about wireless networks. I'd say what the FAQ says is
about right in my experience. It is only an approximate guide...

RP

Stephen Ryan
2004-03-03, 14:33
On Wed, 2004-03-03 at 16:29, Richard Purdie wrote:
> > > The 10% rule seems to date from the days of 10MBit coax style ethernet.
> On
> >
> > If you look carefully I was not using a '10%' rule for 802.11b. I
> > said that in my experience you typically max out less than 50% of
> > rated 11Mb/s, i.e. 5Mb/s. This jives with slimdevices' FAQ:
> >
> > http://www.slimdevices.com/su_faq.html#about-wirelessperformance
> >
> > The '10%' rule I use would be estimating on 100Mb/s ethernet you
> > get about 10MB/s after overhead, etc.
>
> What I said is that the 10% rule dates from the days of coax Ethernet. It is
> no longer valid, especially in a home 100Mb/s switched Ethernet environment.
> As Sean says - try it and see.
>
> I made no mention about wireless networks. I'd say what the FAQ says is
> about right in my experience. It is only an approximate guide...

Actually, looking carefully, it looks to me like there's a byte/bit
confusion here. 100 mega*bit* Ethernet does indeed give roughly 10
mega*bytes* per second in actual throughput; that's 8 bits per byte and
a bit of overhead...
--
Stephen Ryan
Digital Rights Management is bad for all of us:
http://www.bricklin.com/robfuture.htm

Jack Coates
2004-03-03, 23:32
On Wed, 2004-03-03 at 09:59, Sean Adams wrote:
> > It seems you are confusing transfer speed with throughput. Bits are
> > modulated onto an ethernet wire at the stated rate (10/100).
> >
>
> No, I'm not. And you don't have to trust me because I work on ethernet
> devices and TCP/IP stacks for a living. Just give it a try, and you
> can discover what real-world ethernet throughput is empirically. Here's
> my test:
>

:-)

> Also, try a few machines on a shared hub, doing a big transfer
> simultaneously and you'll find it's still not nearly as bad as the
> legends say.

the legends date from a time when disks couldn't even provide data fast
enough to fill the wire and there wasn't enough RAM in the typical
server for caching your 100MB file. At that time, getting to the
potential of your thinnet was not likely, especially since most were
poorly installed and violated some other rules of thumb. Like length,
number of repeaters, proper grounding, and "don't lay your cable
alongside the fluorescent light fixtures."

Wireless reminds me of those times, I've done some big transfers across
my WAP and been momentarily puzzled because my laptop's network access
was so slow :-)
--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
*"just leave me alone in the place where I make no mistakes, in the *
*place where I have what it takes... I'm never going to know you now,*
*but I'm going to love you anyhow." *
*Waltz #2 (XO) from XO by Elliott Smith *
************************************************** ********************

Neil Davidson
2004-03-04, 00:59
my understanding is that you will never see this, just like you will never
see native OGG or ACC decoding in the SB. The chip in the SB is a dedicated
MP3 decoder which can also stream WAV and PCM. There is no facility to add
different codec support to the Squeezebox.

What is your reason for wanting this? I know it would reduce the bandwidth
of a loss less stream, but even with wireless, 170KB/sec isn't a lot.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com]On Behalf Of Daryle A.
Tilroe
Sent: 03 March 2004 06:00
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] Native FLAC?


First let me say: great product!

Only real problem I had setting it up was discovering that
'flac.exe' had to be in the path somewhere for the server to
decode to wav for transmission to the SqueezeBox (this should
really be in a more prominent place in the FAQ).

Anyhow that brings me to my second question:

When might we expect to to see native FLAC decoding at the
SqueezeBox?

My understanding is that it is in principle possible (perhaps
even under development) due to the low horsepower required to
decode FLAC. So to those in the know; how long before we see
firmware capable of this: weeks, months, years, "never; who
gave you that crazy idea"?

--
Daryle A. Tilroe