lolownia wrote:I run FreeBSD 6-STABLE with OSS/FreeBSD 3.99.4b
OSS drivers work great with test and XMMS, however
trying to play sound with GStreamer 0.10.9 produces such error:
creep@carnivore[~]:> gst-launch-0.10 --verbose filesrc location=file.mp3 '!' mad '!' audioconvert '!' osssink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/pipeline0/mad0.src: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)2
/pipeline0/audioconvert0.src: caps = audio/x-raw-int, width=(int)16, depth=(int)16, signed=(boolean)false, endianness=(int)1234, channels=(int)2, rate=(int)44100
/pipeline0/audioconvert0.sink: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)2
ERROR: from element /pipeline0/osssink0: Could not get/set settings from/on resource.
Additional debug info:
gstosssink.c(441): gst_oss_sink_prepare (): /pipeline0/osssink0:
Unable to set device /dev/dsp in non blocking mode: Invalid argument
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/pipeline0/audioconvert0.src: caps = NULL
/pipeline0/audioconvert0.sink: caps = NULL
/pipeline0/mad0.src: caps = NULL
FREEING pipeline ...
Kernel: FreeBSD 6.2-PRERELEASE #1: Wed Sep 27 20:18:33 CEST 2006
VIA 8233 AC97 audio controller at 0x1400 irq 9
0: VT8235 (DUPLEX)
1: VT8235 (shadow) (DUPLEX)
2: OSS Virtual Mixer v2.5 Playback CH #0 (GRC3)
3: OSS Virtual Mixer v2.5 Playback CH #1 (GRC3)
4: OSS Virtual Mixer v2.5 Playback CH #2 (GRC3)
5: OSS Virtual Mixer v2.5 Playback CH #3 (GRC3)
6: OSS Virtual Mixer v2.5 Playback CH #4 (GRC3)
7: OSS Virtual Mixer v2.5 Playback CH #5 (GRC3)
8: OSS Virtual Mixer v2.5 Playback CH #6 (GRC3)
9: OSS Virtual Mixer v2.5 Playback CH #7 (GRC3)
0: OSS Virtual Synth v2.5
0: VT8235 (VT1612A)
1: Virtual Mixer
dsp0: pid 10947 cmd 'esd' OUT
dsp0: pid 10979 cmd 'gst-launch-0.10' OUT
Please do't hestitate to email me (creep @t desk dot pl) if I can provide You with additional data -- You do a very good job!
lolownia wrote:Oh no, this is not the case. I know that two applicatios cannot open the same device, this would return EBUSY, and not EINVAL. The esd in history was killed before my tests.
I tried the configuration with dsp linked to dsp2 and gstreamer reported:
Unable to set device /dev/dsp2 in non blocking mode: Invalid argument
The gstreamer code which does this is contained in gstreamer-plugins-good-0.10.3 in osssink module:
sys/oss/gstosssink.c function gst_oss_sink_prepare
397 oss = GST_OSSSINK (asink);
399 mode = fcntl (oss->fd, F_GETFL);
400 mode &= ~O_NONBLOCK;
401 if (fcntl (oss->fd, F_SETFL, mode) == -1)
402 goto non_block;
Seems gstreamer tries to actually disable non-blocking mode (contrary to error message it displays:
439 GST_ELEMENT_ERROR (oss, RESOURCE, SETTINGS, (NULL),
440 ("Unable to set device %s in non blocking mode: %s",
441 oss->device, g_strerror (errno)));
442 return FALSE;
Maybe this is GStreamer bug, I have no idea about oss standard and non-blocking modes, or how are the applications supposed to detect this.
If GStreamer wants to make their library api abstracted from harware/driver details, they should obviously handle this. But again, my knowledge is too limited to judge this.
Users browsing this forum: Google [Bot] and 1 guest