Re: Unnecessary check for mmap/trigger in audiolib.c

On Sun, 29 May 2011 02:50:21 +0200
Martin Samuelsson <[email protected]> wrote:

> Hi, developers!
> 
> Today, I decided to try setting up some tools for a project of mine. It would 
> involve three lavplays in parallel, and require use of the padsp wrapper for 
> the sound, as I don't have OSS on this computer, and only one hardware channel, anyway.
> 
> I was rewarded with a curious message: "Soundcard cant do mmap or trigger"
> 
> Fair enough, the PA OSS emulation can't do mmap, but that's what lavplay's -U flag 
> is for. Still no cake when using that, though; still the message about no mmap 
> support (which I already knew, and tried to avoid...).
> 
> It turned out that audiolib.c, as far as I can tell, doesn't honor the mmap_io, 
> nor the use_read_write flag, and look for mmap/trigger support even when it 
> shouldn't. My proposed patch takes care of that, skipping the check when read/write 
> is requested instead of mmap.

No reaction at all to this patch? Does it look like an appropriate solution to the 
problem with playing sound through padsp?

> This let me play the audio through padsp, but lavplay will often hang
> with the message "Buffer overflow writing audio". I haven't yet tried
> to improve that situation, but I have observed the hang occur in either one of the
> audio_errno = AUDIO_ERR_BOVFL lines.

Some more digging reveal that the hang occur after a failed
lavplay_queue_next_frame() in lavplay_playback_cycle() has invoked audio_shutdown(), 
in audiolib.c:

void audio_shutdown(void)
{
   if(!initialized) return;

   /* show the child we want to exit */

   shmemptr->exit_flag = 1;
#ifdef FORK_NOT_THREAD
   waitpid(pid,0,0);
#else
   pthread_join( capture_thread, NULL );
#endif

   initialized = 0;
}

If I do not waitpid or pthread_join, lavplay exits instead of hanging indefinitely. 
I interpret this as the audio thread (do_audio()) being locked up in some way, 
not able to react to exit_flag, and thus not able to exit, leaving lavplay 
waiting forever for it to exit

Does this seem like a correct conclusion? Getting debug messages out from the 
audio thread is not the easiest thing to do; how would you proceed with 
the debugging of it?

Regards,
/Sam

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2