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 > [email protected] > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Me joindre en téléphonie IP / vidéoconférence ? sip:[email protected] Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
