Re: [gst-devel] Re: [gnome-love] GStreamer plans and TODO
- From: Benjamin Otte <in7y118 public uni-hamburg de>
- To: Bastien Nocera <hadess hadess net>
- Cc: iain <iain prettypeople org>, Gnome Multimedia Hackers <gnome-multimedia gnome org>, Gstreamer-Devel <gstreamer-devel lists sourceforge net>, <gnome-love gnome org>
- Subject: Re: [gst-devel] Re: [gnome-love] GStreamer plans and TODO
- Date: Mon, 21 Apr 2003 20:14:16 +0200 (DFT)
On 19 Apr 2003, Bastien Nocera wrote:
I said it wasn't a driver issue or a bug in the sound output
plugins/frameworks. Its a simple case that my soundcard simply does not
handle certain (common) audio formats.
So that's either a bug in the driver, that doesn't advertise correctly
which formats are supported, or in the framework for not testing
properly if these formats are supported.
Or it's a bug in ALSA's API, GStreamers autoplugger or whatnot. Imagine
Iains crappy soundcard, which does 22,050 Hz, 44100 Hz and 48000 Hz in 1,
2, 3 and 5 channels with the exception of the combination 44100 Hz / 2
channels.
ALSA reports its capabilities as ranges. *bam* The error you get from
GStreamer's ALSA plugin is "could not set caps", because the advertised
range couldn't exclude this one format.
Other reasons why a capplet might be useful, given a system with OSS,
Alsa, ARTS, ESD, MAS installed, how does one automagically decide which
to use?
That's another discussion altogether... On a GNOME/Linux platform, it
would properly test for the presence and current use of the sound
servers, then ALSA, then OSS.
xine plugins use "priorities" for that.
1) I don't like an #ifdef __linux__ #elif defined (__sgi__) madness for
deciding on sound output.
2) I don't like priorities either.
3) I think it would be nice to have some magic trying to find theright
output when the GConf key is set to empty.
4) I even think it'd be nice to have it default to empty once that magic
works.
Benjamin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]