On Wednesday 30 May 2007 18:05, Takashi wrote:
At Wed, 30 May 2007 08:47:14 +0200,
Clemens Ladisch wrote:
Alan Horstmann wrote:
On Tuesday 29 May 2007 17:55, Takashi wrote:
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);
So are you saying that the same device can reliably be opened both O_RDONLY and O_WRONLY -AT THE SAME TIME but with different numbers of channels? That is a bit counter-intuitive given the ONLY part, but if true would probably provide a workable solution.
I thought of a similar hack but it seems that many apps don't check / set DUPLEX capability. So, this might not work on many apps.
- 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).
But note that the 4front OSS creates lots of devices -see http://manuals.opensound.com/developer/oss_devices.html so they can be opened sparately always.
Right. For example, in the case of audacity, the change would be like the following patch (untested).
Well I quickly hacked something similar to try, and did seem to be able to open input_handle and output_handle separately, and have Audacity 'Duplex recording' so that could be fine. I will do more testing and report back!
Alan