[gst-devel] media-info, and old streaminfo tags

[Christian Schaller]

Ok, let me try and summarize this discussion in the hope that we can
move beyond it :), based on these mails and what I picked up on IRC. We
basically have an issue here with GStreamer causing blockage on crappy
soundscards even when we are not playing anything, just on pause.

Basically I agree with the point that people with such sound cards
should use a soundserver (and there are many such cards out there). In
the GNOME context that still means using esound. 

On a related note I think we have a bug report or someone mentioned that
we cause esd to block the device too when we use it and we have
something on pause, which means we do cause even in this scenario cause
uneeded soundcard blockage for non-esd apps. (yes, I know about esddsp).

Also on the practical side we know that a lot of people do not use
esound or any other soundserver, and we know that these people
(including many developers) will very likely be very unhappy if we do
cause such blockage. 

As I understood Thomas has volunteered to add some stuff to solve this,
but there are objections to it since it is kinda breaking with our
design and not 'the right way' to solve it. And keeping our code and
design clean is important for long term viability and maintainability.
Yet if I have also understood the discussion on IRC the change is not
really that intrusive, so backing it back out for 0.9/1.0 and replacing
it with something better is a viable solution. 

If this is correct I think we should go for Thomas's proposed solution,
even if it is a little 'icky' as it do solve a real world problem for a
lot of people. On the other hand if by adding this we create something
which a lot of stuff will depend on/be designed for. And which will
cause major disruption/need for rewrites/redesigns later on, then I say
we just have to play though and say 'use a sound server' or get a decent
sound card.

Christian

On Sun, 2004-03-07 at 11:09 +0100, Thomas Vander Stichele wrote:
> > > It is clear that there should be a way to "release" devices without
> >   ^^^^^^^^^^^
> > > setting the element to NULL.  This is not only for audio sinks.
> > 
> > No, it is not.
> 
> It is not clear if you keep arguing from a theoretical standpoint, ie
> from the design to the app.  It is easy to be right about this from that
> point of view, because this point of view basically says "if it's not in
> my design then it is not clear we need this."
> 
> What I'm saying is, if you are designing so that apps can use us, then
> it really is clear this should work.  Why is it clear ? Because all the
> music player apps that use GStreamer atm want to be able to release the
> device on pause.
> 
> Feel free to tell me I'm missing the point here.  But don't forget that,
> from the app developer's point of view, it is us who are missing the
> point.  They want to be able to do this, and all we can say is "sorry,
> we don't do that (yet)", and in the back of our heads we think "and we
> never will, suckers, because it doesn't fit our design, muhahah".
> 
> > You mention "setting an element to NULL",
> 
> I mention "setting an element to NULL" because that is what all these
> apps are currently doing to work around this issue.  They are doing this
> because, with the functionality they want, they have no other way.
> 
> >  but you don't actually mean
> > that. You mean, an element not losing its internal state set. However,
> > that's already lost when going to READY. States are documented in the
> > PWG, and that reflects what I perceived as the conclusion from the last
> > time we discussed this.
> 
> Yep - and the last time we discussed this we already KNEW that doing it
> this way would make it impossible for devices to get released without
> setting the sink to NULL.  What does that tell us ? That we designed it
> wrong.
> 
> > About states: we don't need to discuss it, we don't need to document it.
> > I've been working a lot on that lately (PWG), and I'm still intending to
> > work more on it (chapter 4). Let's fix our apps.
> 
> That's like saying "we don't really need to write down any designs for
> GStreamer, it's all in our head".  It's getting really tiring to switch
> internal design stuff around only to find out that while it fixes the
> problem we were having, it creates a whole bunch of new ones we weren't
> having.  The only way to avoid that in the future is to start writing
> down designs and prove *on paper* that apps will work this way.
> 
> If you install fedora core 1, and run rhythmbox, and pause, then play,
> it works.  Currently, when you will install fedora core 2, and do the
> same, it won't.  I'm not entirely sure how much you guys care about the
> negative publicity this will get us, not to mention how hard it will be
> to convince GNOME that we really are improving and that GNOME is making
> the right choice to use GStreamer.
> 
> You also said "Let's fix our apps".  Seriously, I don't see how this is
> a bug in the apps.  There is literally nothing I can think of that the
> apps should do in this respect.  Feel free to say what they should be
> doing.
> 
> Anyways, I can't bring it up more than I already do.  If you all think
> that the current design is fine, and that we can continue sticking our
> head in the sand saying everything outside of GStreamer is wrong, from
> kernel to daemons to userspace apps up, go right ahead :) I'm just
> getting worried about the message we're trying to send here.
> 
> Maybe we should quarantine development of GStreamer for a few years and
> tell apps to come back after that ?
> 
> Thomas
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel