After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 334832 - OSS output not working with 0.10.5 (FreeBSD)
OSS output not working with 0.10.5 (FreeBSD)
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.2
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 316846 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-17 00:53 UTC by Joel
Modified: 2006-08-07 11:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Fix OSS sink on FreeBSD (643 bytes, patch)
2006-04-12 05:39 UTC, Joe Marcus Clarke
none Details | Review

Description Joel 2006-03-17 00:53:11 UTC
Please describe the problem:
Using FreeBSD-CURRENT.  When OSS is selected as the default output, the test
sound succeeds, but trying to play something through Totem (or the command line)
doesn't produce any output.  Selecting ESD works fine.

Steps to reproduce:
1. gst-launch-0.10 audiotestsrc ! osssink  (works!)
2. gst-launch-0.10 filesrc location=SoD-Arials.mp3 ! mad ! audioconvert !
audioresample ! osssink  (doesn't work)
3. 


Actual results:
step 1 produces the annoying sine wave.  step 2 has the following output:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: audioclock0
^CCaught interrupt -- Pausing pipeline.
Pipeline paused.
WARNING: Element "pipeline0" warns: pipeline interrupted
Element "pipeline0" has gone from PLAYING to PAUSED, quitting.
Execution ended after 51750990000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...

And there is never any audio produced.

Expected results:
I'd expect to hear sound.

Does this happen every time?
Yes.

Other information:
Comment 1 Joe Marcus Clarke 2006-03-17 01:20:21 UTC
Additionally, totem built with gst-0.10.5 prints the following warning to stderr when playing an MP3 file.  When the ESD output sink is used, this warning is not seen:

** (totem:96582): WARNING **: could not link audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int){ 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 }, channels=(int)[ 1, 2 ]: -4
Comment 2 Joe Marcus Clarke 2006-04-02 04:41:35 UTC
This looks to be a problem with finding the supported sample rates.  If I hack around the code that cycles through each sample rate, I get the probed OSS capabilities to be good, and thus the sink works.  I'm still investigating a proper solution for this.
Comment 3 David Schleef 2006-04-11 22:48:54 UTC
Could you run the above command with 'GST_DEBUG=oss:5' in the environment and attach the output?
Comment 4 Joe Marcus Clarke 2006-04-12 05:37:54 UTC
I'm sorry I did not reply to this earlier.  This problem is FreeBSD-specific, and I have added a workaround hack to our ports tree.  Well, now that I think about it, maybe it's not FreeBSD-specific, but the hack is.

The problem is that OSS will report the last successful rate if a bad rate is set.  FreeBSD doesn't support a rate of 1000 (4000 is our smallest).  Therefore, on each pass through the various formats, the minimum rate was always being reset to the last maximum rate from the previous format.

The attached patch is what I used to correct this problem on FreeBSD.  After this, and some other fixes to our gst ports, gst-0.10 is working magnificiently on FreeBSD.
Comment 5 Joe Marcus Clarke 2006-04-12 05:39:02 UTC
Created attachment 63281 [details] [review]
Fix OSS sink on FreeBSD
Comment 6 David Schleef 2006-04-12 19:27:08 UTC
From the OSS Programmer's guide:

"For this reason the driver always computes the valid frequency which is closest to the requested one and returns it to the calling program."

I'd like to see something that says this is specifically untrue for FreeBSD's implementation of OSS.
Comment 7 Joe Marcus Clarke 2006-04-22 17:48:21 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."
Comment 8 Tim-Philipp Müller 2006-04-25 19:44:55 UTC
Moving to -good where osssink lives.

David, is this the same problem as in bug #311586 ?

Comment 9 David Schleef 2006-04-25 20:25:52 UTC
No, I'm pretty sure it has nothing to do with matroska.  Perhaps you meant a different bug?
Comment 10 Tim-Philipp Müller 2006-04-25 22:05:13 UTC
Sorry, I meant bug #316846.
Comment 11 David Schleef 2006-04-25 22:28:17 UTC
*** Bug 316846 has been marked as a duplicate of this bug. ***
Comment 12 Jan Schmidt 2006-05-06 20:18:48 UTC
Is there a resolution for this bug yet? Anything we need to do?
Comment 13 David Schleef 2006-05-08 23:23:37 UTC
I still speculate that this is due to a driver bug.  The log file in the duplicate bug is clearly a driver bug.  Dunno about this one, since there's no log file attached.
Comment 14 Christian Fredrik Kalager Schaller 2006-05-12 14:23:14 UTC
Joel and Joe Marcus, what is the current status for GStreamer 0.10 on FreeBSD? After posting a blog entry recently there where claims of GStreamer 0.10 not even building under *bsd, but considering we have a bug report discussing a possible bug in osssink I assume at least core, base and good compiles fine :)
Comment 15 Joe Marcus Clarke 2006-05-12 16:05:13 UTC
If built from the FreeBSD ports collection, GStreamer 0.10 builds and runs just fine on FreeBSD.  I think it will build just fine out of the box.  The only runtime issue is with OSS, and the patch attached to this bug fixes that.  That patch should no longer be needed after the next round of audio changes.
Comment 16 Joel 2006-05-12 17:07:05 UTC
Yes, OSS output has been working for a while now on FreeBSD.
Comment 17 Christian Fredrik Kalager Schaller 2006-05-12 18:41:40 UTC
ok, thanks for the quick response Joe and Joel. I don't see any reason to keep this bug open then. Closing.
Comment 18 David Schleef 2006-05-12 18:47:43 UTC
What change is being made to the driver?  The log file in the duplicate bug shows that the driver returned 0 and set rate to a seemingly random number.

Could someone add a link to a cvsweb page for the implementation of the rate ioctl?  I'd like to figure out what exactly is going on, and make sure as many problems get fixed simultaneously.
Comment 19 Joe Marcus Clarke 2006-05-12 18:53:30 UTC
The rate is not set to a random number.  It is set to the last successful rate (which is very high due to the looping through all supported formats).  My understanding is that FreeBSD's dehavior will be changed such that the smaller rate (1000).  The code for FreeBSD's sound driver can be found at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pcm/ .