[gst-devel] RFC: cooperating osssrc/osssink

[Erik Walthinsen]

On Sun, 13 May 2001, Thomas Nyberg wrote:

> Here is one problem, not every card supports full duplex, even worse - some
> cards only supports 16bit for output and then 8bit for input if you go
> to full duplex!!! This makes the drivers really ugly to write :(
Yeah, true, but the problem is that there are too many drivers for
hardware that don't have these problems, but don't support multi-open.
Yeah, fix the drivers, but they aren't going away.  If the hardware does
indeed have screwy requirements like that, then we can safely tell the
user to go spend $5 to get a card that doesn't suck.

> Depending on the actual OSS-driver(kernel-driver), it should not be any
> problem with one instance opening the card for reading and one for writing.
But that's the whole point.  steveb at least has an ess1688 that doesn't
allow that for one reason or another.

> I don't think it is a very nice idea to allow multiple instances of
> osssink. This adds much complexity to an element that doesn't need to
> have that functionality. I might have misunderstood you here, though. But
> if you want multiple instances of the osssink, the same functionality
> can be achieved with _one_ instance and then a mixer-element.
Yeah, I agree with you there.  Just a thought <g>

> Since I've totally spammed this list for a couple of month now, I don't
> think anyone hasn't noticed the alsa-stuff.(I'm sorry, but bear with me
> a little while longer) It has support for multiple cards, even cards
> with multiple PCM's attached to them. Okey, ALSA has some nice functions
> for this and so on... But it would be really cool if the OSSsink also
> supported multiple cards, multiple PCM's/card and so on...
Yeah, though multiple cards with OSS are just different devices, so we
should just add a location argument that defaults to /dev/dsp.

> It shouldn't be to complicated to add it - using the ALSA-stuff as a
> base and building on that code.
Well, there's a problem there.  The ALSA sink you have is going about it
the wrong way.  There should be only one elementfactory called 'alsasink',
and you set the card,device,subdevice as arguments.  Then the appropriate
pads get created at NULL->READY, when the device is opened for the first
time.

> Where am I going then? Well, the addition of support for OSS and
> multiplte soundcards/PCM's and so on... should be added. Since I did
> the ALSA-variant of this, I could also spend the time to do this one.
Just make sure you ditch the multiple factories first <g>  A plugin
shouldn't touch any hardware until it's got an element that's in READY or
higher state.

The thing is to decide how we want to go about having the application
determine what devices are available.  In the OSS case it's a little
fuzzy, since you really have to do a lot of work to decide: open
/dev/sndstat, parse it, search /dev for nodes with the right major/minors,
etc.  ALSA makes it a bit easier ;-), but then, we have to squeeze this
somehow through the g[tk]object get/set interface.  That'll be fun <g>

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_