Re: Converting OSS ioctl's to ALSA API

[James Courtier-Dutton <James@superbug.co.uk>]

Bob Ingraham wrote:

>Thank-you so much for ioctl mapping!
>
>May I ask one other architectural question?
>
>This video-conferencing app expected to use two half-duplex devices for
>simultaneous record-playback:
>
>/dev/dsp0 and /dev/dsp1 - these were expected to be configured as the
>separate playback and record channels of a single soundcard.
>
>However, on all of our target platforms (all running
>SuSE/Novell-Linux-Desktop,) there only appears to be a single, full-duplex
>device to use (plugwh:0,0) for both record and playback.
>
>So the (three-part) question is:
>
>1. Do I:
>
>  (a) Try to re-write this app to use full-duplex? or,
>
>  (b) Can I re-configure ALSA to split the default device (plughw:0,0)
>into two separate, half-duplex sub-devices (one for playback and one for
>record?
>
>
>2. Which approach makes more sense (i.e., more stable, reliable, etc.)?
>
>
>3. If 1a is the way to go, is there a tutorial or sample-doc on how to
>properly program full-duplex (simultaneous record & playback) operation
>under ALSA?
>
>
>Thanks,
>Bob
>  
>
ALSA provides an abstraction layer.
If you open plughw:0,0 for only playback, and then again for only 
capture it should work.
So, although the device name looks the same, device names for playback 
and capture are in fact in a different name space.
alsa-lib does all the difficult work for you.

Another alternative could be to use jackd. It is ideal for low latency 
applications, and VoIP is certainly ideal for that.

James



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf