yet another full duplex wannabe

["Henry \"Drew\" W. Abbot, Jr." <hwa5c@virginia.edu>]

Greetings,
   I'm trying to achieve a full-duplex sound processing app with ALSA.  
I've been messing around with various code examples for days now, and 
I've started hitting some of (what seems to be) the same ol' 
difficulties any newbie encounters when trying to tackle full duplex 
with ALSA.  For now, the goal is simply to simultaneously capture from 
plughw:0,0 and playback to plughw:0,0.  I've gotten a few "working" test 
apps -- by "working", I mean I can hear stuff, but the sound is really 
choppy -- that is, I'll hear captured sound for one period, then I'll 
hear about one period of silence while readi blocks, then another period 
of sound, then another period of silence, etc. (this can resemble the 
sound of a helicopter) -- anyway, the net result is an ugly and 
distorted capture.  The main two test apps I'm working with right now 
are both based on the pcm.c example.  In one, I essentially turned the 
write_loop into a readwrite_loop, and in the other, I use two threads 
(via pthreads), one to capture and one to playback.  I've only messed 
with the standard interleaved, blocking interface.  From the discussion 
at 
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg09937.html, 
I assume a better approach would be to use snd_async_add_pcm_handler() 
and/or mmapped access and snd_pcm_avail_update() on both capture and 
playback PCMs.  However, should I be running the capture and playback in 
separate threads or in the same thread?  In separate processes (i.e. 
fork() vs. pthreads)?  Intuitively, separate threads seems like it could 
help, but I should be calling writei pretty soon after calling readi 
completes (right?), so it also seems like having them run in separate 
threads would complicate things.  Right now, I've tried to "hack it," 
such that whenever readi is blocking, sound will still be playing from 
the last writei (is this conceptually accurate?), but to no avail.  
Messing with the period and buffer sizes changes the "helicopter effect" 
somewhat (i.e. for smaller periods, the sound has a tendency to blow up 
/ be unstable -- I guess this is feedback), but basically it's the 
same.  At first, I thought I was just way off, but after running the 
latency.c example and getting the same "helicopter-like" results, I 
gained back some confidence.  I even tried running 'ecasound -i 
alsahw,0,0 -o alsahw,0,0' and it, too, yielded similar results.  I 
didn't try messing with period or buffer sizes with ecasound, but I 
tried many with latency.c and nothing seemed to produce smooth, 
undistorted sound.  Surely, I don't have to apply low-latency patches or 
something to simply run a full-duplex userland app, do I?  I know what 
you guys want to say... I should just forget about all of it and use 
JACK, and yes, I am already at the JACK website reading the 
documentation, but I would like to get my own lower-level ALSA code 
working, too.  In summary, my questions are:
   1) Any ideas on why latency.c and ecasound aren't working smoothly?
   2) Any advice on whether to use the standard ALSA interface, the 
async, the mmap, etc. for a full duplex app?
   3) Any advice on single-threaded vs. multi-threaded?
   4) Should my capture and playback PCMs be configured the same way?  
I.e. how about this for an app.. should I have a smaller period size for 
capture, and capture each little bit at a time, and when the time comes 
around to send another larger period for playback, I can send however 
many smaller capture periods I have received at that time.

Thanks for your time, and sorry for such a long post.


Best,
Drew




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV