Buffering for Radio Streaming

[Triode]

Hi,

I've been looking the architecture for buffering streaming audio and have a couple of suggestions I'd like to share with the list
for comment.

To minimise dropouts through lost packets and variable round trip times on the internet (at least on my part of it!) really needs a
few seconds of buffering. Streaming mp3, this is reasonably OK as the player has a reasonable buffer due to the raw mp3 stream
being sent to the player - the buffer can handle a few seconds worth at the low rate most streams are encoded in. However when
playing back any other form of stream e.g. ogg via server side decode (oggdec) without transcoding via lame, the buffer on the
player is handling pcm and hence is far less tollerant of drop outs on the stream. At present there is minimal other buffering in
the system. This is OK if the decoding application can be configured to perform reasonable buffering itself [the lastest AlienBBC
takes this approach], but not if simple decoders like oggdec are used. A simple solution is to configure a player for transcoding
via bit rate limiting, but then this impacts all audio, rather than just streaming audio.

I've though about the following approaches to this:

1) [Easiest] Add the option for a separate bit rate limiting setting for remote streams - so that lame can be used for remote
streams only, to enable them to benefit from a larger buffer.
2) [Hardest, most strategic?] Build in a extended bounded buffer into slimserver to buffer a few seconds of pcm in slimserver as an
extension of the player buffer for remote streams.
3) Add the ability to use different conversion commands for "local" and "remote" so that a different decoding app can be used
streams [e.g. ogg123 instead of oggdec], or an alternative command line, potentially including an external buffer utility in the
chain, can be included.

I think the first option would suit most people, but as I use a dac I'd really rather avoid the L/R swap digital out problem on a
Squeezebox by doing server side decode of mp3.... so I am tempted to look at the others. However has anyone else had this problem -
is it a problem worth solving?

Adrian

[Jack Coates]

Triode wrote:
> Hi,
>
> I've been looking the architecture for buffering streaming audio and
> have a couple of suggestions I'd like to share with the list for comment.
>
> To minimise dropouts through lost packets and variable round trip times
> on the internet (at least on my part of it!) really needs a few seconds
> of buffering. Streaming mp3, this is reasonably OK as the player has a
> reasonable buffer due to the raw mp3 stream being sent to the player -
> the buffer can handle a few seconds worth at the low rate most streams
> are encoded in. However when playing back any other form of stream e.g.
> ogg via server side decode (oggdec) without transcoding via lame, the
> buffer on the player is handling pcm and hence is far less tollerant of
> drop outs on the stream. At present there is minimal other buffering in
> the system. This is OK if the decoding application can be configured to
> perform reasonable buffering itself [the lastest AlienBBC takes this
> approach], but not if simple decoders like oggdec are used. A simple
> solution is to configure a player for transcoding via bit rate limiting,
> but then this impacts all audio, rather than just streaming audio.
>

True.

> I've though about the following approaches to this:
>
> 1) [Easiest] Add the option for a separate bit rate limiting setting for
> remote streams - so that lame can be used for remote streams only, to
> enable them to benefit from a larger buffer.
> 2) [Hardest, most strategic?] Build in a extended bounded buffer into
> slimserver to buffer a few seconds of pcm in slimserver as an extension
> of the player buffer for remote streams.
> 3) Add the ability to use different conversion commands for "local" and
> "remote" so that a different decoding app can be used streams [e.g.
> ogg123 instead of oggdec], or an alternative command line, potentially
> including an external buffer utility in the chain, can be included.
>
> I think the first option would suit most people, but as I use a dac I'd
> really rather avoid the L/R swap digital out problem on a Squeezebox by
> doing server side decode of mp3.... so I am tempted to look at the
> others. However has anyone else had this problem - is it a problem
> worth solving?
>
> Adrian
>
>

I've had it, or I assume that was the problem -- I find that non-mp3
radio is generally less reliable. Of the proposed solutions, 2 is over
my head. 3 looks best for Linux/Mac but challenging for Windows (may
make support get interesting as well).

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

[dean]

2 wouldn't be that hard to do, you'd need to set a select callback on
it that filled up the buffer and then uninstalled itself when it got
full, reinstalled itself when it got some space. And it would be the
most general.

In any case, it would be good to file a bug on this for us to rally
around.



On Jan 29, 2005, at 8:56 AM, Jack Coates wrote:

> Triode wrote:
>> Hi,
>> I've been looking the architecture for buffering streaming audio and
>> have a couple of suggestions I'd like to share with the list for
>> comment.
>> To minimise dropouts through lost packets and variable round trip
>> times on the internet (at least on my part of it!) really needs a few
>> seconds of buffering. Streaming mp3, this is reasonably OK as the
>> player has a reasonable buffer due to the raw mp3 stream being sent
>> to the player - the buffer can handle a few seconds worth at the low
>> rate most streams are encoded in. However when playing back any
>> other form of stream e.g. ogg via server side decode (oggdec) without
>> transcoding via lame, the buffer on the player is handling pcm and
>> hence is far less tollerant of drop outs on the stream. At present
>> there is minimal other buffering in the system. This is OK if the
>> decoding application can be configured to perform reasonable
>> buffering itself [the lastest AlienBBC takes this approach], but not
>> if simple decoders like oggdec are used. A simple solution is to
>> configure a player for transcoding via bit rate limiting, but then
>> this impacts all audio, rather than just streaming audio.
>
> True.
>
>> I've though about the following approaches to this:
>> 1) [Easiest] Add the option for a separate bit rate limiting setting
>> for remote streams - so that lame can be used for remote streams
>> only, to enable them to benefit from a larger buffer.
>> 2) [Hardest, most strategic?] Build in a extended bounded buffer into
>> slimserver to buffer a few seconds of pcm in slimserver as an
>> extension of the player buffer for remote streams.
>> 3) Add the ability to use different conversion commands for "local"
>> and "remote" so that a different decoding app can be used streams
>> [e.g. ogg123 instead of oggdec], or an alternative command line,
>> potentially including an external buffer utility in the chain, can be
>> included.
>> I think the first option would suit most people, but as I use a dac
>> I'd really rather avoid the L/R swap digital out problem on a
>> Squeezebox by doing server side decode of mp3.... so I am tempted to
>> look at the others. However has anyone else had this problem - is it
>> a problem worth solving?
>> Adrian
>
> I've had it, or I assume that was the problem -- I find that non-mp3
> radio is generally less reliable. Of the proposed solutions, 2 is over
> my head. 3 looks best for Linux/Mac but challenging for Windows (may
> make support get interesting as well).
>
> --
> Jack at Monkeynoodle dot Org: It's a Scientific Venture...
> Riding the Emergency Third Rail Power Trip since 1996!
>