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>).
Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
