Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

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.

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