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