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
