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

Hallo

It takes most of the time a little bit longer-

>> 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?
I have just added you patch to the CVS.

> 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?
The conclusion sounds correct. But I have no idea of how to proceed.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: [email protected]
www: http://www.lysator.liu.se/~gz/bernhard

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev