[gstreamer-bugs] [Bug 334832] OSS output not working with 0.10.5 (FreeBSD)

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=334832
 GStreamer | gstreamer (core) | Ver: 0.10.5





------- Comment #7 from Joe Marcus Clarke  2006-04-22 17:48 UTC -------
This is from our sound system maintainer:

"Quote from OSS Programmer's Guide

Sampling rate is the parameter that determines much of the quality of
an audio sample. The OSS API permits selecting any frequency between 1
Hz and 2 GHz. However in practice there are limits set by the audio
device being used. The minimum frequency is usually 5 kHz while the
maximum frequency varies widely. Some of the oldest sound cards
supported at most 22.05 kHz (playback) or 11.025 kHz (recording). The
next generation supported 44.1 kHz (mono) or 22.05 kHz (stereo). With
modern sound devices the limit is 96 kHz (DVD quality) but there are
still few popular cards that support just 44.1 kHz (audio CD quality).

- Ok, luckily our current sampling rate converter support from 1Hz to
  8388607Hz (that is 8GHz!). It is just that we intentionally set its
  limit to 4khz - 200+/- khz for sane operation.

[..]

Codec devices usually generate the sampling clock by dividing the
frequency of a high speed crystal oscillator. In this way it is not
possible to generate all possible frequencies in the valid range. For
this reason the driver always computes the valid frequency which is
closest to the requested one and returns it to the calling program.
The application should check the returned frequency and to compare it
with the requested one. Differences of few percents should be ignored
since they are usually not audible. A larger difference means that the
device is not capable to reproduce the requested sampling rate at all
or it may be currently configured to use some fixed rate. Also note
                                                          ^^^^^^^^^
that this call rarely returns an error (-1). Getting an OK result
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
doesn't mean that the requested sampling rate was accepted. The value
                                                            ^^^^^^^^^
returned in the argument needs to be checked.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [2]

1. OSS set its default range from 1hz-2GHz, so this seems valid and
   acceptable. All we need is to lower/raise our imposed limit to
   replicate this behaviour.
2. Sad enough, most applications does not do proper checking on this,
   instead rely totally on [1] return value, which somehow coherent
   with our current behaviour to fail right on the spot.

Actually, our behaviour is correct. Once we "fix" our imposed limit,
everything should be exactly like what OSS does.
...
It is an intended "feature" :) . It will be fixed."


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.