[gst-devel] RFC: cooperating osssrc/osssink

[Thomas Nyberg]

On Sun, May 13, 2001 at 12:20:02AM -0700, Erik Walthinsen wrote:
> With a lot of drivers, it's not possible to open /dev/dsp once for reading
> and once for writing, at the same time.  In most cases it *is* legal
> however to open the device once and set it to FULLDUPLEX mode.
>
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 :(

> So my thought is for osssrc and osssink to cooperate, identifying when any
> combination of sources and sinks are set to use the same device.  At that
> point, the first element to go to READY is responsible for open()'ing it
> and setting things up as necessary.  Futher elements in READY acquire the
> filedescriptor, and cooperate in accessing it.  If there is only one
> source and sink, they can proceed blissfully unaware of each other (I
> think), just read()ing and write()ing.
>

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

(hmm... after writing this, I am pretty sure that I misunderstood your
point :)

> A more interesting (though maybe not useful?) case is multiple sources
> and/or sinks.  In that case, whichever one gets to the device first in any
> instant in time would squirrel away the buffer in a queue so others can
> pull copies of them.
> 
> Anyway, I'll just be happy enough getting shared src/sink working.  Would
> probably have to have a plugin-level data structure shared between the two
> elementfactories, and a hash from device pathname to element attached.
> 

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...
It shouldn't be to complicated to add it - using the ALSA-stuff as a
base and building on that code. There are some big differences between
OSS and ALSA 0.5.x, since some cards doesn't support stream-mode only
block-mode it becomes rather ugly. Look at the alsa-code, and view
the big difference in complexity. For a block-mode you need a buffer
of your own and so on... In ALSA 0.9.x this is fixed and hidden away
inside the ALSA-libraries(much nicer)...

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.

However, I haven't grasped what it is that you really want, though :)
(not hard to figure out by looking at my babling ;)

/Thomas <thomas at codefactory.se>

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