slimserver DOES support 22kHz, SPDIF does not.  You should still get streaming
playback via the analog audio outs.  Some digital inputs do work, but others do
not accept anything outside of the specification for SPDIF.

But according to kdf response at
http://lists.slimdevices.com/archives/discuss/2004-November/038960.html
this is a server problem.

The patch for bug 624 (https://bugs-archive.lyrion.org/show_bug.cgi?id=624) is
related, but isn't a complete fix for the Ogg case. 

To get this to work correctly, we will need to:
1) Either find out the sample rate of the Ogg file/stream a priori (easier to do
with a local file than a stream) or somehow get this information from oggdec.
2) Have a resampling step in the pipeline. The simplest solution would be to use
lame to do the resampling, though with loss of quality. To use lame, we'd need
to have a convert.conf entry that took the input sample rate/sample size -
current lame command lines assume 44.1KHz input.
3) Alternatively, we could write upsampling code in SlimServer itself. For
22.05KHz -> 441.KHz, sample doubling would probably be an acceptable (though not
ideal) option.

I'm not an expert on this, but my understanding is that Squeezebox will play
back uncompressed PCM streams at sampling rates 22.05kHz, 44.1kHz, or 48kHz. I
assume that the server in some way tells the client the samplimg rate of the
incoming stream.
Based on this, it seems like the first step should be to get correct playback
without any transcoding in the server, i.e. streaming the PCM output from oggdec
directly to the client. I assume that the PCM output stream of oggdec has the
same sampling frequency as the OGG input. The server then needs to get sampling
rate information from oggdec, and set up the client accordingly. The ogg streams
play perfectly using winamp (which also correctly displays the sampling
frequency), and the OGG decoder therefore should have a means of exporting this
sampling frequency.

The next step (necessary to also support slimp3) would then be to get LAME
working with non-standard sampling frequency input. This should preferably be a
general interface independent of the original format, in this case ogg.

vidur:  sox it to me!

Another example: http://ogg.tv-radio.fr:1441/encoderfip.ogg @ 32khz

Another option for a fix to this bug is to use sox (http://sox.sourceforge.net/)
instead of oggdec for decoding. With sox, we should be able to set the output
sample rate to 44.1KHz. Anyone care to try this out (i.e. find the right
convert.conf command line for ogg->wav conversion using sox and see if that works)?

Same issue with version 6 as of 03/13/2005 !

As well as the example Simon posted, it's actually all the French Public Radio
streams:

> France Inter : http://ogg.tv-radio.fr:1441/encoderfinter.ogg
> France Info : http://ogg.tv-radio.fr:1441/encoderfinfo.ogg
> France Culture : http://ogg.tv-radio.fr:1441/encoderfculture.ogg
> France Musiques : http://ogg.tv-radio.fr:1441/encoderfmusiques.ogg
> FIP : http://ogg.tv-radio.fr:1441/encoderfip.ogg
> Le Mouv' : http://ogg.tv-radio.fr:1441/encoderlemouv.ogg
> Hector : http://ogg.tv-radio.fr:1441/encoderhector.ogg
> La CityRadio de Paris : http://ogg.tv-radio.fr:1441/encodercityradio.ogg

The problem is that oggdec does not offer the possibility to resample the input
stream as the decoders for the other formats do. Oggdec's output stream is
locked to the sample rate of the input stream, and oggdec is also not capable of
converting mono to stereo.

I have only looked into a server-side fix for this, as I am not able to assess
the possibility of implementing a fix in Squeezebox firmware.

I have looked into three different solutions for decoder setup in convert.conf:

1. Using lame for resampling:
ogg mp3 * *
   [oggdec] -Q -o - -R $FILE$ | [lame] -s $SAMPLE_RATE_IN_kHz$ -m
$NO_OF_CHANNELS_DESCRIPTOR$ --resample 44100 -q $QUALITY$ --silent -b $BITRATE$
-r -x - -
A requirement for this to work is that SAMPLE_RATE_IN_kHz (e.g. 32) and
$NO_OF_CHANNELS_DESCRIPTOR$ (m for mono, s for stereo) needs to be available.
The solution will also only work when transcoding to MP3, not when streaming PCM
to Squeezebox. I have been successful in playing back the problematic ogg
streams when hardcoding the known properties of the streams.

2. Using sox for resampling:
ogg mp3 * *
   [oggdec] -Q -o - -R $FILE$ | [sox] -t raw -r $SAMPLE_RATE_IN_Hz$ -c
$NO_OF_CHANNELS$ -w -s - -t raw -r 44100 -c 2 -w -s - | [lame] --resample 44100
-q $QUALITY$ --silent -b $BITRATE$ -r -x - -
ogg wav * *
   [oggdec] -Q -o - -R $FILE$ | [sox] -t raw -r $SAMPLE_RATE_IN_Hz$ -c
$NO_OF_CHANNELS$ -w -s - -t raw -r 44100 -c 2 -w -s - 
A requirement for this to work is that SAMPLE_RATE_IN_Hz (e.g. 32000) and
$NO_OF_CHANNELS_DESCRIPTOR$ (1 for mono, 2 for stereo) needs to be available.
The solution will work both when transcoding to MP3, and when streaming PCM to
Squeezebox.
I am running WinXP, and needed a patch for sox in order to get it to read from
stdin. Patch can be found at
http://shnutils.freeshell.org/shntool/
I have been successful in playing back the problematic ogg streams when
hardcoding the known properties of the streams.

3. Using sox for decoding ogg:
ogg mp3 * *
    [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s - | [lame] --resample 44100
-q $QUALITY$ --silent -b $BITRATE$ -r -x - -
ogg wav * *
    [sox] -V -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s -
The advantage of this solution is that no parameters describing the input stream
needs to be provided.
However, I have not got it to work on my WinXP system. I needed to build sox
with the ogg and vorbis libraries in order to get ogg decoding capabilities. I
also needed to do some minor modifications of the source (in addition to the
stdin patch) in order to get it to compile with Visual Studio 6.0. My sox build
works when decoding an ogg file, but I haven't been able to get it to work when
trying to decode an ogg radio stream. When trying to decode the ogg stream, ogg
uses 90%-100% of my CPU without producing any output. I don't know if this is a
fundamental problem with sox, or if it is just my build that is the problem. May
be sox will only need a small patch in order to be capable of decoding ogg radio
streams?

I am not qualified to comment on the technical aspects of steinar's proposed
solutions - but as a user, I would find a solution that required me to create
bookmarks or other parameters that defined a stream, plus some hard-coded
attributes of the stream, to be perfectly acceptable.

I did some tweeking of the libvorbis and sox source code:
1. Forcing vorbis streams to not be seakable (vf->seekable=0;) in vorbisfile.c
2. Reducing BUFFSIZE from 8192 to 4096 in resample.c
3. Some Visual Studio specific modifications

With this sox build I was able to play back correctly all the problematic
oggvorbis radio streams using these settings in convert.conf:
ogg mp3 * *
     [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s - | [lame] --resample 44100
-q $QUALITY$ --silent -b $BITRATE$ -r - -
ogg wav * *
    [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s -x -

In conclusion, it is possible to use sox for decoding of ogg radio streams
(including mono and non-standard sample rates) without any modifications of the
slimserver software.

I hope SlimDevices can take it from here, and close this bug.
Please contact me if you need further information.

Steinar, this is great! I will do some testing on the various platforms and
confirm that we're able to use sox cross-platform. If you believe that there's
more information I might need to compile sox correctly, please send it to me
directly. Thanks!

Checked in sox binaries for Windows, OS X and i386 linux. Also checked in
changes to convert.conf to use sox for ogg decoding. Should appear in 3/23/05
nightlies.

Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.