[Icecast] low bandwidth broadcasting using ices2

[Andy Baxter]

Is there any way to bring the bitrate in ices2 down below 32 kbps?

I'm setting up a demo for someone of how to use linux to do net radio
broadcasting. The setup I'm thinking of is to use ardour plus jack to mix
two (maybe more) input sources (live audio and recorded
tracks/programmes), then send the mixed audio to ices2 for streaming to
icecast2, using the jackified version of ices2. This is all working OK.

The problem is, I'm trying to set it up to use peercast peer to peer
streaming, so as to cut down the amount of bandwidth that the server
needs. This means every listener needs to have enough bandwidth to relay
at least one stream out as well as in. What I was thinking of is to
broadcast 2 ogg streams ; one at 64kbps stereo for broadband listeners,
and another at 16kbps mono for dialup listeners, and maybe get a few
people with good connections to have a permanent peercast relay for both
these streams. But as far as I can see, ices2 won't encode at below 32
kbps, which won't work with peercast on 56k dialup links.

I remember from the vorbis documentation that it's supposed to work down
to 16 kbps per channel, and the old vorbis encoder for linux used to do
this, so has something changed in the specification?

Specifically, I have a machine with 2 versions of oggenc on it, one
from debian woody, and one compiled from source. The woody version will
encode mono wavs down to 16kbps, but the (later) hand compiled version
will only go down to 32 kbps. The quality of the 16kbps files isn't that
great, but it's still ok to listen to - no obvious distortion or spurious
noises, just a loss of clarity.

If there's any way to get ices2 to encode to 16kbps mono, could someone let
me know how?

-- 
Please don't send me html mail or un-notified attachments. These will be 
automatically filed under 'probable spam' unless I'm expecting an email which 
hasn't come.
If you do need to send an attachment or html mail, put [attachment] or [html] 
in the subject line.
Thanks, andy.