Raw audio streams (was: New poll for slimp3-users)

[Martin Hay]

Yep - wireless networks hark back to old-style networks with hubs/repeaters rather than switches. Typically you could get about 60% of the theoretical 10Mb/s on those. Any more, and the network would start to choke on packet collisions. The same thing applies for the wireless networks, since again all the traffic is being sent on the same common medium (switches direct the network traffic over direct paths sort of like phone exchanges directing phone calls, for those who don't know).

Anyway, the upshot of this is you could optimistically get 3 streams at once (given a little protocol overhead). Maybe 4 if you have a good clean signal. If you need more, get yourself an 802.11g wireless LAN. 54Mb/s should cover plenty of tunes. If you're like me, running your server on old hardware that's lying around, you'd be struggling with the server before the network I expect.

Ho-hum, back to work...

Martin.


-----Original Message-----
From: Mikko Hänninen [mailto:Mikko.Hanninen (AT) iki (DOT) fi]
Sent: Wed 12/11/2003 16:06
To: discuss (AT) lists (DOT) slimdevices.com
Cc:
Subject: [Discuss] Raw audio streams (was: New poll for slimp3-users)



(Replying here to thread about raw audio streams from the old list...)

Ron Thigpen <keihin (AT) null (DOT) net> wrote on Fri, 07 Nov 2003:
> If a standard 802.11b network could support one or two of these streams
> (at CD quality audio) then this would seem to be a reasonable way to add
> support for other formats w/o having to implement h/w encoding for more
> types or going to a general purpose processor design.

CD quality audio is stereo (2-channel) 16 bit samples at 44100 hertz
sample rate, so 44100 * 16 * 2 = 1411200 bits/second (about 1.4 Mbit/sec).
Typical WLAN speed is 11Mbit/sec, so in theory you can fit 7 CD-quality
raw audio streams in that. However in practice you can't really get that
much, there's overhead from the data transfer protocol used, and in any
case the theoretical maximum is usually quite theoretical (which is the
more important limiting factor). Still, at least one and maybe even two
streams should be possible, if the connection is good.


Mikko
--
// Mikko Hänninen, aka. Wizzu // sig (AT) wizzu (DOT) com // http://www.wizzu.com/
// The Corrs list maintainer // net.freak // DALnet IRC operator/
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs/
Constant change is here to stay.

[Ron Thigpen]

> -----Original Message-----

> From: Mikko Hänninen [mailto:Mikko.Hanninen (AT) iki (DOT) fi]
> Sent: Wed 12/11/2003 16:06
> To: discuss (AT) lists (DOT) slimdevices.com
> Cc:
> Subject: [slim] Raw audio streams (was: New poll for slimp3-users)

> (Replying here to thread about raw audio streams from the old list...)
>
> Ron Thigpen <keihin (AT) null (DOT) net> wrote on Fri, 07 Nov 2003:
> > If a standard 802.11b network could support one or two of these streams
> > (at CD quality audio) then this would seem to be a reasonable way to add
> > support for other formats w/o having to implement h/w encoding for more
> > types or going to a general purpose processor design.
>
> CD quality audio is stereo (2-channel) 16 bit samples at 44100 hertz
> sample rate, so 44100 * 16 * 2 = 1411200 bits/second (about 1.4 Mbit/sec).
> Typical WLAN speed is 11Mbit/sec, so in theory you can fit 7 CD-quality
> raw audio streams in that. [...] Still, at least one and maybe even two
> streams should be possible, if the connection is good.


So, an 802.11b WLAN with decent signals should support def. one and
probably two raw, CD-quality streams. 802.11g will support more, is
available, and cheap enough. And, of course, a wired LAN would support
more than either of these WLAN options.

From this, I'd have to say that raw audio streaming would be a decent
way for the Slim to provide playback support for just about any format
that comes along. The audio server machine could perform decoding
instead of transcoding, avoiding an extra processor burden and the
negative sonic implications. Any DRM unlocking could be done in the
context of the active server session.

The network bears a greater burden, but not to an unworkable extent. As
time goes on, either greater network capacity (more raw streams) OR more
processor power (transcode to MP3) could be applied as an upgrade path.

Client software would be free to evolve along with the file formats.

As far as the poll is concerned, I thought it was important for people
to understand that when they were voting for raw audio support, they
were really voting for OGG, WMA, AAC, etc. (though not implemented in
the same manner as MP3 support).

--rt

[Phil Nelson]

On or about 11/12/2003 09:12 AM PST, Ron Thigpen wrote:

> > -----Original Message-----
>
>> From: Mikko Hänninen [mailto:Mikko.Hanninen (AT) iki (DOT) fi] Sent: Wed
>> 12/11/2003 16:06 To: discuss (AT) lists (DOT) slimdevices.com Cc:
>> Subject: [slim] Raw audio streams (was: New poll for
>> slimp3-users)
>
>
>> (Replying here to thread about raw audio streams from the old
>> list...)
>>
>> Ron Thigpen <keihin (AT) null (DOT) net> wrote on Fri, 07 Nov 2003:
>> > If a standard 802.11b network could support one or two of these
>> streams
>> > (at CD quality audio) then this would seem to be a reasonable
>> way to add
>> > support for other formats w/o having to implement h/w encoding
>> for more
>> > types or going to a general purpose processor design.
>>
>> CD quality audio is stereo (2-channel) 16 bit samples at 44100 hertz
>> sample rate, so 44100 * 16 * 2 = 1411200 bits/second (about 1.4
>> Mbit/sec).
>> Typical WLAN speed is 11Mbit/sec, so in theory you can fit 7
>> CD-quality
>> raw audio streams in that. [...] Still, at least one and maybe
>> even two
>> streams should be possible, if the connection is good.
>
>
>
> So, an 802.11b WLAN with decent signals should support def. one and
> probably two raw, CD-quality streams. 802.11g will support more, is
> available, and cheap enough. And, of course, a wired LAN would
> support more than either of these WLAN options.
>
> From this, I'd have to say that raw audio streaming would be a decent
> way for the Slim to provide playback support for just about any format
> that comes along. The audio server machine could perform decoding
> instead of transcoding, avoiding an extra processor burden and the
> negative sonic implications. Any DRM unlocking could be done in the
> context of the active server session.
>
> The network bears a greater burden, but not to an unworkable extent.
> As time goes on, either greater network capacity (more raw streams) OR
> more processor power (transcode to MP3) could be applied as an upgrade
> path.
>
> Client software would be free to evolve along with the file formats.
>
> As far as the poll is concerned, I thought it was important for people
> to understand that when they were voting for raw audio support, they
> were really voting for OGG, WMA, AAC, etc. (though not implemented in
> the same manner as MP3 support).
>
> --rt


I was voting for flac, at least I wanted to. It seems kind of foolish to
stream 1.4 Mbit/sec when you can cut it in half or better with no loss
of sound quality. Especially over wireless.

--
Phil Nelson

[Ron Thigpen]

Phil Nelson wrote:

> On or about 11/12/2003 09:12 AM PST, Ron Thigpen wrote:

>> [...]
>> As far as the poll is concerned, I thought it was important for people
>> to understand that when they were voting for raw audio support, they
>> were really voting for OGG, WMA, AAC, etc. (though not implemented in
>> the same manner as MP3 support).
>
> I was voting for flac, at least I wanted to. It seems kind of foolish to
> stream 1.4 Mbit/sec when you can cut it in half or better with no loss
> of sound quality. Especially over wireless.


Not necessarily foolish, but certainly a trade-off: network usage v. CPU
usage. Depends on which resource you have "enough" of.

Does anyone have an estimate of how much CPU would be consumed for
realtime compression of one CD quality stream to FLAC? For units, I'm
think of rough percentages of a standard CPU, ex: 20% of an
AthlonXP2400. Granted, this will vary based on system config. Just
thinking in rough terms here to get into the ballpark.

Adding FLAC support might also raise the price of the client device
(Slim), as it would neccessitate an additional decoding capability in
the device. Raw will have its own client requirements, but would
presumably be simpler to implement.

--rt