[gst-devel] Device enumeration problems

[Erik Walthinsen]

OK, we've got a problem that needs to be solved somehow.  Several ideas
have been tossed on the table, I've come up with one more.  First, the
problem:

In researching the construction of an ALSA source and sink component
(which I need to do multitrack audio), there's the problem of device
capabilities.  Specifically, the number and type of input or output
pads.  For a regular soundcard, and with OSS, we putn and assume that
everything is ok.  This is at odds with the whole caps thing, but not so
much that it's bit us yet.

For ALSA, and especially in my case, we have to be much more careful.  
You can open one device and get a mono output channel at 8khz, while
another device presents you with 24 channels in and out at 48KHz with a
bit-depth of 24 (one of my cards).  This can only be determined by
actually opening the card.

Now, the audiosink (OSS) simply assumes that everything is A-OK.  You set
audio parameters and the audiosink just gives it a shot.  I don't think it
even checks, so if your sound card doesn't do what you want it to, you get
odd results (like, shattered eardrums).

One suggestion was to open the device(s) at element creation.  This has
numerous problems, even if the devices are opened and immediately closed
to find their capabilities, then the real open happens at READY.  In that
case, what if the device disappears or another appears in the meantime?

We can't do it on the way to READY, since the whole idea of READY is that
the pipeline is already ready to go.  create_plan runs from NULL to READY,
and if we can't connect things because the pads don't exist, in turn
because the device hasn't been probed, well, that's a problem.

Two other solutions come to mind;

1) add another state in between NULL and READY for device probing and
other operations.  This brings us back to the original five-state system
from ages past.  In order to make it as transparent as possible, we could
even hide it from users and add a flag to the element such that the state
system treats these elements differently.

Or we could expose the state and state that in order for some elements
(anything with a hardware dependence) to be able to fully instantiate
themselves, you have to set them to this state, which otherwise is
equivalent to NULL.  All other elements wouldn't care.  The extra code
that would require (every element would have to treat NULL and the new
state the same way) could again be mitigated by having the library state
functions act as if NULL->READY is the normal way of doing it.

2) Add a bit to the elements that state that they need to be probed.  Add
a probe function to the elements in question that must be explicitely
called.  A bin-level version would recurse and call all of them.  Signals
could be added in places where it's obvious that probing is the solution,
when it hasn't already occured.  That means that in get_pad, if there are
no pads, the signal "needs_probe" would fire.  An app that knows what it's
doing could connect to that signal and deal with it.  Else there could be
a flag that causes the probe to happen automatically.


Of these two, I prefer the extra state.  It will cause some extra work to
be done if we want to keep everyone else blissfully ignorant, but is
localizable into the element_set_state() function.

Comments?

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user