Re: [Ekiga-list] PTLIB alsa plugin status

[yannick <sevmek free fr>]

Le vendredi 27 février 2009 à 09:37 +0100, Alec Leamas a écrit :
> Derek Smithies wrote:
> > Hi,
> >
> > On Fri, 27 Feb 2009, Alec Leamas wrote:
> >
> >> Hm... a write operation could be guaranteed to return in finite time 
> >> (using non-blocking io + snd_pcm_wait). So couldn't the close method 
> >> just mark the chanell as closing, leaving the dirty work to the 
> >> "writer" thread and thus avoiding the locks? (Which, otoh, really 
> >> isn't a big issue in this scenario). If required, opening could be 
> >> handled in the same way, I guess. This would also create the 
> >> advantage that the thread could process the jitter buffer data in 
> >> parallel with the alsa output, without the need to wait for the IO to 
> >> complete. Wouldn't this give a more accurate timing? Also, avoiding 
> >> blocking io is a Good Thing IMHO.
> >
> > No.
> > It must be a blocking write. The architecture of opal demands this.
> >
> > The play thread (using play as an example) repeatedly does the following
> >   read rtp packet from jitter buffer
> >   decode
> >   put raw audio to sound device (which delays for up to framesize of
> >                           packet)
> >
> I didn't really make my point clear, sorry. I understand that the write 
> method should block, and  my code does this, it's just a question how 
> it's implemented. Refactored to a write method:
> 
> write( pcm,  chunk)
>     if( closing)
>         close(); return();
> 
>     snd_pcm_wait( pcm, timeout)
>         // Blocks until there is a free frame in alsa buffer,
>         // the same time as a blocking write would, using the
>         // the same "timer", but with a timeout option. 
> 
>     if( timeout)
>         // Underrun? Check status & handle error.
>     else
>         write( pcm, chunk) // non-blocking
> 
> 
> The basic difference is that this code will never block indefinitely -  
> thus making it it possible to remove the locks. Depending on the 
> blocking, alsa write implementation it might also give a slightly better 
> timing. But I shouldn't count on it.
> 

I've no clue if this documentation might help, still the pulse audio
main author refers it as "a guide":
http://0pointer.de/blog/projects/guide-to-sound-apis.html

Especially the section "You want to know more about the safe ALSA
subset?"


> >
> > There was a time when pwlib and openh323 (the old names of ptlib and 
> > opal)
> > used non blocking writes to the sound card plus software timers. the 
> > software timers were found to not be reliable enough to delay the 
> > write thread. Sometimes the delay was hundreds of milliseconds. So 
> > openh323 and pwlib were changed to use blocking writes, which gave 
> > much better audio performance.
> >
> > to change the operation of the write to be non blocking would have 
> > major architectural implications to opal. Let me help you. This won't 
> > happen.
> Agreed
> 
> Coming back to the other issues. Unfortunately, I'm the victim of 
> https://bugzilla.redhat.com/show_bug.cgi?id=481722, having a hard time 
> to to test Ekiga. I'll do what I can, though.
> 
> _______________________________________________
> ekiga-list mailing list
> ekiga-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-list
> 
-- 
Me joindre en téléphonie IP / vidéoconférence ?
sip:yannick ekiga net
Logiciel de VoIP Ekiga : http://www.ekiga.org
http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F