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.

_______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list

Reply via email to