[alsa-devel] Alsa-OSS Duplex bug (revisited)
Alan Horstmann
gineera at aspect135.co.uk
Mon May 28 00:23:13 CEST 2007
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.
Regards Alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcm_oss.c-1.0.14rc4-duplex-channels-set.diff
Type: text/x-diff
Size: 2826 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070527/1137971d/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pa-oss-duplex-chans-fix.diff
Type: text/x-diff
Size: 2978 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070527/1137971d/attachment-0003.bin
More information about the Alsa-devel
mailing list