yet another full duplex wannabe

yet another full duplex wannabe

[Henry "Drew" W. Abbot, Jr.]

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

Re: yet another full duplex wannabe

[Henry "Drew" W. Abbot, Jr.]

Whoops!  So, first of all, the feedback was due to me not muting PCM 
Playback via the mixer, haha.  No wonder there was so much feedback!  No 
wonder ecasound et al didn't work!  Doh!  Anyway, by realizing this 
silly mistake and coming up with better code, I achieved my goal.  If 
anyone cares to look at, laugh at, and/or criticize some code, advise me 
to use the async interface, take a different approach etc. here's what I 
got:
http://people.virginia.edu/~hwa5c/code/fulldup8b.c

Best,
Drew


Henry "Drew" W. Abbot, Jr. wrote:

>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
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>  
>


-------------------------------------------------------------------------
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

Re: yet another full duplex wannabe

[Kai Vehmanen]

Hi,

On Mon, 22 Jan 2007, Henry "Drew" W. Abbot, Jr. wrote:

>   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

have you tried the code on another computer, and/or with different 
soundcard? That sounds like a driver problem. The most basic:

sh> arecord -f cd - |aplay -f cd -

... should produce acceptable audio quality in most cases. Getting that to 
work reliably, with all kinds of soundcards, and with a low latency, is 
somewhat trickier (and this is when I'd recommend taking a look at JACK 
:)). But simple full-duplex recording'n'playback should work 
out-of-the-box...

> 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

In most cases you want to run in the same thread, or otherwise you need 
complicated measures (as done in JACK) to synchronize the different 
execution contexts, and to keep the cost of these contexts switches at a 
reasonable level.

> 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

This really is pointing towards a driver/hw bug... latency.c has always 
worked for me (and I've been using it with dozens of ALSA versions and 
soundcards).

> 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

That should work as well ... in majority of cases, ecasound will tune the 
buffering parameters automatically (based on what you've asked ecasound to 
do).

> 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

No patches of any sort should be needed for the basic functionality
(latency.c) to work.

> 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:

You could of course install JACK and test whether you get the same
helicopter effect with it, too? That would potentially help to track down 
the problem.

-- 
  links, my public keys, etc at http://eca.cx/kv

-------------------------------------------------------------------------
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