At Sun, 27 May 2007 23:23:13 +0100, Alan Horstmann wrote:
About a year ago I posted an explaination of the cause of non-functioning with Alsa-OSS in duplex, together with a workaround patch. After some discussion the thread ended. However since then there has been a steady trickle of downloads of the patches from my host (it can also be found elsewhere) and some reports of great success,eg
http://audacityteam.org/forum/thread/1388 (2nd page especially)
In attempting to tidy up some loose ends, I hope you can bear with me revisiting this and making the case for it's acceptance. I am aware the Alsa-OSS is not of much interest to developers, and it might be said 'use native Alsa'; however that is not possible or desirable in all applications, and anyway, why provide an OSS emulation that cannot be made to work properly?
To summarise the problem first:
OSS provides a single SNDCTL_DSP_CHANNELS ioctl; where a device is duplex the number of capture and playback channels cannot be set separately. With original OSS this was not a problem AFAIK because separate devices are created for capture and playback, ie they are not used duplex. However Alsa-OSS in most cases creates a single combined device, which only operates correctly when an equal number of capture and playback channels are used.
The Workaround:
The workaround I proposed and now use constantly is like a secret trapdoor. Where the existing interface is adequate (ie captue channels == playback channels, or non-duplex) nothing changes, and SNDCTL_DSP_CHANNELS is set with a number between 0 and 128. It is fully compatible with apps that don't know of the secret door -the front door is used!
However, if an app needs to set capture channels != playback channels, in duplex, at present the stream will malfunction every time. But with this patch applied, if the app knows the workaround, then it can simply set SNDCTL_DSP_CHANNELS as playback + 256*capture channels, and this will be interpreted correctly in the patched Alsa-OSS and the stream functions correctly.
As I say, there is therefore no loss of compatibility in either direction. Providing the app only uses the special formula when necessary rather than always, it is only providing a way to fix something that is broken. It would seem to me of value to add the patch to Alsa so that the workaround can be effected by changes to the app only, without also having to patch and compile a replacement Alsa. Whilst it is by no means ideal, it does overcome the underlying problem successfully. Details of the workaround could be added to the OSS-Emulation.html document.
Patch for 1.0.14rc4 is attached for consideration, together with example portaudio patch.
Thanks for the patch. I see how you struggled with this problem.
Well, this is a bit hard problem to decide which to go. 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.
So, I'm not fully convinced by this change yet.
OK, let's whip this dead horse again.
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?)
or
- change portaudio to open each direction separately, O_RDONLY and O_WRONLY at first, then use O_RDWR as fallback
Are these feasible?
Takashi