[thomas@codefactory.se: Re: [gst-devel] RFC: cooperating osssrc/osssink]

[Thomas N. <th...@co...>]

----- Forwarded message from Thomas Nyberg <th...@co...> -----

From: Thomas Nyberg <th...@co...>
To: Erik Walthinsen <om...@te...>
Subject: Re: [gst-devel] RFC: cooperating osssrc/osssink

On Mon, May 14, 2001 at 01:12:15AM -0700, Erik Walthinsen wrote:
> On Sun, 13 May 2001, Thomas Nyberg wrote:
> > 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.
>

<pun>
Well, you have already answered this:
  > 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.
</pun>

But, yeah - you're right. It should not be to much problem to save the
filedesriptor when it is opened. A static global variable should solve
this one. 

> > 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.
>

Mainly the issue there was, that I was looking at the LADSPA-stuff, and
saw a correlation between their multiple-plugins and my multiple-cards.

> > 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>  

As you command... I will do that as soon as possible, I never liked
this approach anyway. The problem is that I will need to create some
nice structures or whatever to notify the "user" about which cards
are present - their names and so on... But it should be possible
to do this in a semi-effective way.

> A plugin
> shouldn't touch any hardware until it's got an element that's in READY or
> higher state.

This is not possible in the case where you have multiple unknown instances
and so on... In the ALSA-stuff I try to probe the caps for the card - since
support for cooler stuff is hardly availible on every card. It would be
possible to skip this feature and assume 44kHz, 16-bit, stereo. But I
think we would loose a lot of "power" by doing it this way.

Then it is better to probe the hardware upon init of the plugin, atleast
to the point as to determine what hardware is availible. One could create
the pads and their caps when it's time for negotiations and so on... I
think that would be ok... However, back to the point, you still need to
probe the hardware for the number-of-cards-present and so on... I really
don't think we should do it any other way. Comments?

> 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>
> 

There is always the simple approach:
 - one get_number_of_cards(...) which returns the number of cards <g>
 - one get_card_name(int card) - returning the name of the card
 - one set_card_to_use(int card) - which tells this instance of the sink/src
   to use this card-num. The number need only reflect some internal
   position in the sink/src. It doesn't need to be usable for anyone
   on the "outside". The "name" of the card should be enough for this.


And I still hope that the DynParams will be implemented soon, it
will be a much niver interface than with gtk_object_set/get...
Another advantage with doing it "our" way, is that we might be able
to return something meaniful - to alert the caller if the setting
failed or worked :)

/Thomas <th...@co...>

-- 
Thomas Nyberg                    tho...@co...
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64


----- End forwarded message -----

-- 
Thomas Nyberg                    tho...@co...
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64