[alsa-devel] Alsa-OSS Duplex bug (revisited)

[Alan Horstmann]

On Wednesday 30 May 2007 07:47, you wrote:
> Alan Horstmann wrote:
> > On Tuesday 29 May 2007 17:55, you wrote:
> > > While I see the advantage by your hack (small and backward
> > > compatible), I feel that it's too hackish -- it introduces an
> > > incompatible way of the existing ioctl.
> >
> > Do you mean in that ioctls in general are not meant to work like that, in
> > effect passing 2 numbers rather than one?
>
> No, packing two values into one numbers is done with other ioctls too,
> e.g., SNDCTL_DSP_SETFRAGMENT.
>
> The problem I see is that your patch changes the OSS API in a way that
> is incompatible with every implementation other than ALSA's.  The whole
> purpose of providing the OSS API in the first place is to be compatible
> with other implementations.
>
> > > After a quick thought, another possible fix would be to let apps open
> > > each direction separately.  For that,
> > >
> > > - add some way to make the given PCM stream to non-fullduplex
> > >   (proc or module options?)
> >
> > Are you thinking that if an option were set, Alsa-OSS would create
> > separate devices for capture and playback rather than a single duplex
> > device?
>
> No; just a way to disable DSP_CAP_DUPLEX and/or SNDCTL_DSP_SETDUPLEX.
> When these do not work, applications are forced to open the playback
> and capture devices separately, e.g.:
>
> fd_playback = open("/dev/dsp", O_WRONLY);
> fd_capture = open("/dev/dsp", O_RDONLY);
>
> > > - change portaudio to open each direction separately, O_RDONLY and
> > >   O_WRONLY at first, then use O_RDWR as fallback
>
> This would be the preferred way.  After all, this is the only way that
> is possible with the existing OSS API when you want to use different
> sample formats, and it is recommended in all cases (see
> <http://manuals.opensound.com/developer/full_duplex.html>).

My reading of the 4Front info is different.  I read that they recommend best 
opening SEPARATE devices, one O_RDONLY and the other O_WRONLY, in their 
scheme called 'twodevice'.  It also states in fulldup.c:-

"... The one device full duplex scheme requires that the device file is opened 
with O_RDWR."

Whereas what is being suggested here is to open /dev/dsp twice simultaneously, 
O_RDONLY and O_WRONLY which 4Front definitely doesn't propose.

The crutial point is that Alsa-OSS at present isn't really compatible with 
4Front etc BECAUSE they implement separate NON-duplex devices for each 
capture and playback channel pair, whereas Alsa-OSS just has one, duplex!  If 
for example I use the 4Front driver for my DMX6fire, then 
(-see:	http://manuals.opensound.com/developer/oss_devices.html)

I would have 11 non-duplex devices, which can be opened separately to record 
and play to the card without the channels-set problem.  With Alsa-OSS I have 
just one!  Even if Alsa-OSS had just the 'all outputs' and 'all inputs' 
devices that would be fine.

It seems odd that an OSS emulated device is provided to an audio card that 
could have differing numbers of capture and playback channels, eg 4 capture 
and 2 playback, but it is impossible to set 4C and 2P when opening it for 
simultaneous capture and playback.  The underlying stream has no problem with 
doing so, it is just there is no way to pass the numbers.  My workaround is 
to solve an incompatibility that already exists.  It seems 4Front avoids this 
by creating non-duplex devices.  The patch extends the functionality of the 
ioctl in a way that only Alsa-OSS may need, (or perhaps all OSS should 
adopt?).

Alan