Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit : Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlib&opal. The default values for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. With the standard 8 kHz codecs, there is not more than 2-3 errors on 1 Mbyte of data using a two periods hw buffer and a 150 ms jitter buffer from Sweden to the echo server. I've added logging code to the alsa driver to show this. I have not been able to get any usable results using the 16 kHz codecs against 5...@ekiga.net (no sound at all...). If the jitter buffer is decreased to 50 ms there are more errors, but then the sound is so bad anyway that it's not a valid usecase. Thinking about it, I can't really see why two or three periods should be a problem unless the jitter buffer is to small (or the system overloaded). And it's the user who sets the jitter buffer. I really think the defaut value should be smaller 2 (or 3) on Linux. Question is how to adjust this value if needed. Yet another "hidden" gconf variable? Is it needed, can this be handled by the jitter buffer? Anyway, this is a way to get rid of 40-60 ms of latency on Linux, more on windows. I think it deserves to be thought of, it is a substantial gain. BUt bot until the release is out :-) --a PS: I can now accept calls with the gtk message box. This used to crash. DS --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Damien Sandras wrote: [cut] Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. This patch will break with some hardware, even on Linux. Yes. OTOH, having a 5 periods hardcoded value for all hardware means, on 8 kHz, 100 ms latency where a value of 40-60 ms would be sufficient for many (most?) hw configurations. I still regard this as a bug, although this patch, which is more like a test case, is to simple. Stay tuned until there is some testing... Besides, things like this should definitely be declared instead of being hardcoded values in implementation code :-) --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit : > Derek Smithies wrote: > > On Sat, 28 Feb 2009, Alec Leamas wrote: > > > >> Derek Smithies wrote: > >>> Hi, > >>> > >>> On Fri, 27 Feb 2009, Alec Leamas wrote: > I need a whisky. > >>> Coffee is much better. Don't add any impurities though (milk, sugar > >>> etc) > >> I'm was actually using both whisky AND coffe w milk. Sorry, no > >> offense... :-) > >> > >> After some serious fights w the build system, I've been able to add a > >> simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed > >> output: > >> > >> 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 > >> 13:45:49.402 ALSADevice default Opened > >> 13:45:49.438 ALSASetting buffers, size: 320, count: 5 > > > > It is set in opal in > > > > OpalAudioMediaStream::OpalAudioMediaStream( > > where soundChannelBuffers is set to the supplied parameter value. > > > > This comes out of the pcssendpoint class, which > > > > which ends up coming from: a method of the pcss endpoint which gets > > the user defined buffer depth... > > soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() > > > > > > so you know what ? > > > > I think this is a bug from outside of ptlib&opal. The default values > > for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and > > 3 buffers(windows). > > > > Derek. > > > Indeed. I have submitted a temporary patch to > http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but > should be better than today. If it not makes other problems > visible...Many thanks for your help with his, I wouldn't really have a > chance without it. > This patch will break with some hardware, even on Linux. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Sorry for the noise. I've had problems w my email, lost control over what's really sent. -a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlib&opal. The default values for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. Indeed. I have submitted a temporary patch to http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but should be better than today. If it not makes other problems visible...Many thanks for your help with his, I wouldn't really have a chance without it. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
On Sat, 28 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 It is set in opal in OpalAudioMediaStream::OpalAudioMediaStream( where soundChannelBuffers is set to the supplied parameter value. This comes out of the pcssendpoint class, which which ends up coming from: a method of the pcss endpoint which gets the user defined buffer depth... soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth() so you know what ? I think this is a bug from outside of ptlib&opal. The default values for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and 3 buffers(windows). Derek. which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, On Sat, 28 Feb 2009, Alec Leamas wrote: Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) No offense taken. I put that comment in to lighten the tone a little. After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: yeah - it is much easier to avoid such battles and put in cerr statements... These battles are a pain and a complete waste of time. They really really annoy me. Like, autoconf was supposed to remove hassle. It hasn't. The kernel does not use autoconf -- which suggests to me that autoconf is not all capable. The ptlib&opal build system consists of multiple projects that interdepend on each other. autoconf (ideally) requires us to duplicate code and directories, and separate the projects out. forget that. Derek. > Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) I'm was actually using both whisky AND coffe w milk. Sorry, no offense... :-) After some serious fights w the build system, I've been able to add a simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed output: 13:45:49.348 ALSASetting buffers, size: 3840, count: 5 13:45:49.402 ALSADevice default Opened 13:45:49.438 ALSASetting buffers, size: 320, count: 5 which verifies Andreas' logs i. e., this is what causes the oversized alsa hw buffer. I made a quick search, there are no references to SetBuffers in the plugin code. So these calls comes from the upper layers. For the moment I'll stick to the alsa plugin and will not investigate this any further. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, On Fri, 27 Feb 2009, Alec Leamas wrote: I need a whisky. Coffee is much better. Don't add any impurities though (milk, sugar etc) Later on, I'll try refine the documentation for PsoundChannel. cool. Email any docs you have to me directly, and I will add them to the inline documentation in the ptlib sources. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
On Fri, 27 Feb 2009, yannick wrote: 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?" This is a great link. There are some non optimal components in the alsa plugin, or rather, things that are not "safe". I have some sadness at this - the alsa plugin in ptlib was "copied" from the example they provided. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
yannick wrote: 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?" These kinds of hints are always welcome! And I can make us all happy when saying that both the current implementation and the changes discussed are within this safe set. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
About the sound_alsa::write: As of today, both PsoundChannel abstract definition and the method comment in psound_alsa mentions a writeTimeout, with the obvious functionality. However, this is not implemented by the actual code. So: something is wrong, but what? Code? comment? Or? Seems that sound_alsa::read has the same problem. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: [ cut, replied earlier today...] I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Yes. I *think* I've seen five periods hardcoded somewhere... First of all: an overview. You state that the the hw buffering should be two periods, each period 30 or possibly 20 ms. You havn't mentioned sample rate(?), I assume for the moment that we agree on 8 kHz. This would be the interface between the codcc and the sound_alsa stuff. The 20/30 ms is a requirement from the codecs, implemented by the alsa read/write methods. Andrea has debug printouts from the settings when doing a voice call, see the thread "A comparisom ALSA-PULSE" a few days ago. Basically, this boils down to 8Khz, period size 160 frames == 20ms, hw buffer size = 800 frames = 5 periods == 100 ms. This is the sound_alsa /pulse emulated alsa interface settings. The buffer is way to large. And when I take a new look today by making a cat of the /proc/asound files I find rate: 44100, period_size: 8192 == 18.5 ms buffer_size: 16384 == 37 ms. This is the real stuff, the way pulse handles the alsa device. Bottom up: I'm not worried about the 44.1 kHz. Pulse is designed to convert our 8kHz stream to a 44.1 kHz one without any problems. But we should be aware of that what we see in /proc/asound is what pulse sets up against the hw; our settings vs pulse is another issue. I missed that. sound_alsa.cxx/pulse: I really need to look into the code here Here are a lot of hardcoded values, no symbolic constants... seems that the buffer is initially 4 periods (storedPeriods is initiated to 4). The setBuffer calls changes storedPeriods and thus buffer size - at a glance the code looks OK. So: a simple PTRACE in SetBuffers should reveal how the buffers are set. For the moment, I presume that this is how the codec's requirement on a specific sample rate is implemented. I need a whisky. Later on, I'll try refine the documentation for PsoundChannel. Answer: There are two entities that I have seen which can "store" audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. As I suspected. Thanks also for this. So basically we have network latency, jitter/echo cancellation buffer and the device/alsa buffer, all in total preferably in the 150 - 200 ms range. If there is no echo cancellation, the alsa buffer (if larger) could also be jitter buffer. But not if fancy things like echo cancellation should be performed (?). You may have the answer here. How much delay does the speex echo cancellor introduce ? No idea. Anyone, out here? But we seem to have is a 100 ms alsa hw buffer, which will be added to any other buffers involved, including the echo cancellation buffer. it is defaulted to.. The thing is that when looking at the alsa device from the operating system level (in the /proc filesystem) it's clear that the buffer is 5 periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So something is not as expected... Is the simple truth that the alsa period size doesn't match the codec chunk size? But even if so, should it matter? "suspicious" Alsa probably introduces a delay/buffering of its own when you do alsa<-->pulse conversions. Can you repeat the above test on an older distro where the machine does not have pulse? Havn't any, and I havn't had any luck using sound in my VirtualBox VM:s either :-( Derek. --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
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:yann...@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
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
Re: [Ekiga-list] PTLIB alsa plugin status
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) 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. I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Yes. I *think* I've seen five periods hardcoded somewhere... Can you find the hardcoded bit? And report it? Answer: There are two entities that I have seen which can "store" audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. As I suspected. Thanks also for this. So basically we have network latency, jitter/echo cancellation buffer and the device/alsa buffer, all in total preferably in the 150 - 200 ms range. If there is no echo cancellation, the alsa buffer (if larger) could also be jitter buffer. But not if fancy things like echo cancellation should be performed (?). You may have the answer here. How much delay does the speex echo cancellor introduce ? it is defaulted to.. The thing is that when looking at the alsa device from the operating system level (in the /proc filesystem) it's clear that the buffer is 5 periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So something is not as expected... Is the simple truth that the alsa period size doesn't match the codec chunk size? But even if so, should it matter? "suspicious" Alsa probably introduces a delay/buffering of its own when you do alsa<-->pulse conversions. Can you repeat the above test on an older distro where the machine does not have pulse? Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote:
Hi,
On Thu, 26 Feb 2009, Alec Leamas wrote:
Just to sort his out, trying to understand the overall requirements.
Which is a very reasonable thing to do, and it is a good question.
And with the idea that using threads is perfectly reasonable in this
context :-)
Excellent. This idea is very reasonable.
-Let's focus on the playback case, leaving any read aside (which
refer to a different alsa device).
Good idea.
- This should mean that while one thread (A) is closing it's
playback device, another thread (B) starts writing to it.
Yes, thread B is writing audio to the playback device. Thread B is
collecting the data off the jitter buffer,
decoding the audio using the specified codec,
sending the data to the playback device.
thread B is stopped by a bad write to the playback device. Typically,
a bad write to the playback device is caused by the playback device
being closed.
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.
Something like
while(1) {
if( closing)
close(); return
chunk = process_jitter_buffer();
snd_pcm_wait( pcm, timeout)
if( timeout)
// close or prepare...
else
snd_pcm_write( pcm , chunk) // non blocking
}
In the gui thread, user clicked hangup, and a close down thread is
created. This close down thread runs independantly of the gui (so does
not hold up the gui so responses work ok) and makes a call to
OpalCall::Clear() (which is a structure inside Opal) which then goes
through all the RTP threads (including audio) and closes the devices.
Since the Open, Close and Read/Write operations are atomic, there is
no possibility of one happening while the other happens and breaking
things.
The Opal thread which does the call to device Open then goes on to
launch the read/write threads. So read/writes don't run before the
device is open.
Thanks. So there are never any io operations in parallell, but parallell
io/close operations. I think I understand. A good explanation, BTW. I
might submit a patch with documentation to the plugin base class
clarifying this, basically what we have here.
I don't think this aspect of the the Opal design is a problem. The
problem we are are trying to address is the reason for the buffering -
why is there a 100ms delay???
Yes. I *think* I've seen five periods hardcoded somewhere...
Answer:
There are two entities that I have seen which can "store" audio to
give you a delay.
The jitter buffer, which can store seconds of audio.
There are status variables in the jitter buffer which indicate how
long it is buffering audio for.
As I suspected. Thanks also for this. So basically we have network
latency, jitter/echo cancellation buffer and the device/alsa buffer, all
in total preferably in the 150 - 200 ms range. If there is no echo
cancellation, the alsa buffer (if larger) could also be jitter buffer.
But not if fancy things like echo cancellation should be performed (?).
The sound device. Opal sets the sound device (on linux) to store 2
buffers of audio, which is (at most) 2 x 30ms.
One of the 30ms buffers is the buffer currently being written to the
sound device.
The second 30ms buffer is the next buffer to be written.
The buffering depth is set by the call to
devices/audiodev.cpp:bool PSoundChannel_EKIGA::SetBuffers (PINDEX
size, PINDEX count)
size is <=480 (480 is for a 30ms long buffer. GSM uses 20ms.)
count is typically 2 (windows uses 3 or more)
It "is" possible that this call is not happening at the right time. I
doubt this, but you could verify this with a review of the logs.
If this command was being missed, the sound device would get whatever
value it is defaulted to..
The thing is that when looking at the alsa device from the operating
system level (in the /proc filesystem) it's clear that the buffer is 5
periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So
something is not as expected... Is the simple truth that the alsa
period size doesn't match the codec chunk size? But even if so, should
it matter? "suspicious"
Derek.
--a
___
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, On Thu, 26 Feb 2009, Alec Leamas wrote: Just to sort his out, trying to understand the overall requirements. Which is a very reasonable thing to do, and it is a good question. And with the idea that using threads is perfectly reasonable in this context :-) Excellent. This idea is very reasonable. -Let's focus on the playback case, leaving any read aside (which refer to a different alsa device). Good idea. - This should mean that while one thread (A) is closing it's playback device, another thread (B) starts writing to it. Yes, thread B is writing audio to the playback device. Thread B is collecting the data off the jitter buffer, decoding the audio using the specified codec, sending the data to the playback device. thread B is stopped by a bad write to the playback device. Typically, a bad write to the playback device is caused by the playback device being closed. In the gui thread, user clicked hangup, and a close down thread is created. This close down thread runs independantly of the gui (so does not hold up the gui so responses work ok) and makes a call to OpalCall::Clear() (which is a structure inside Opal) which then goes through all the RTP threads (including audio) and closes the devices. Since the Open, Close and Read/Write operations are atomic, there is no possibility of one happening while the other happens and breaking things. The Opal thread which does the call to device Open then goes on to launch the read/write threads. So read/writes don't run before the device is open. I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay??? Answer: There are two entities that I have seen which can "store" audio to give you a delay. The jitter buffer, which can store seconds of audio. There are status variables in the jitter buffer which indicate how long it is buffering audio for. The sound device. Opal sets the sound device (on linux) to store 2 buffers of audio, which is (at most) 2 x 30ms. One of the 30ms buffers is the buffer currently being written to the sound device. The second 30ms buffer is the next buffer to be written. The buffering depth is set by the call to devices/audiodev.cpp:bool PSoundChannel_EKIGA::SetBuffers (PINDEX size, PINDEX count) size is <=480 (480 is for a 30ms long buffer. GSM uses 20ms.) count is typically 2 (windows uses 3 or more) It "is" possible that this call is not happening at the right time. I doubt this, but you could verify this with a review of the logs. If this command was being missed, the sound device would get whatever value it is defaulted to.. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. Just to sort his out for my simple mind, trying to understand the overall requirements. And with the idea that using threads is perfectly reasonable in this context :-) - Let's focus on the playback case, leaving any read aside (which refer to a different alsa device). - This should mean that while one thread (A) is closing it's playback device, another thread (B) starts writing to it. - Which means that thread B has been able to open the device before thread A finished closing it(?) - Which means that I am a little confused... is this as designed? What am I missing? --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
On Thu, 26 Feb 2009, Alec Leamas wrote: But there *are* problems. A well behaved alsa driver should work better aganist pulse, other does. The hw buffer is way to large, 100 ms latency instead of ~50. No statistics. No rebuffering. But you have convinced on one, important point: it should be possible to enhance the driver with a set of smaller patches instead of a major rewrite. Such things are always easier. And I have absolutely no intention to look under the hood in the opal framwork. I just found Andreas' posting, and realized that I had some odd experience in alsa which might be useful. And after looking into this, I still feel that a better alsa interface in Ekiga is really important to get better latency and quality, both of which are crucial in a voip context. Or? BTW, are you the one which have an overall understanding the complete buffering scheme in Ekiga? I understand the ptlib and opal side of things quite well. I had a look at Ekiga, and read about the classes AudioInputCore and AudioInputManager. These Audio classes are necessary to deal with sound device insertion/deletion - such as inserting a USB headset. My first thought was that the OS (not the app) should deal with device insertion/deletion, but Alsa does not. Pulse is supposed to deal with sound device insertion/deletion. The ubuntu forums are full of people complaining about pulse. There is no buffering mechanism in Ekiga that I saw. Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, On Wed, 25 Feb 2009, Alec Leamas wrote: Hi :-) Thanks for this info! As you state, this should work as long as they are instantiated in a proper way. And it's simple just to add some assertions to make sure that this is indeed the case. I still don't get why the device pointers needs locking. Is the overall Ekiga design such as there are several threads writing concurrently? Or is this a general requirement for the driver, for other scenarios the Ekiga? In other words , is the PTlib alsa driver defined as reentrant? yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. It is not the overall Ekiga design that sets the requirment for coping with multiple threads - it is a the PTLib/OPAL design that sets the requirement for coping with multiple threads. The discussion topic of threads and too many threads and so on has occuppied many hours at conferences, and many emails, and is slightly tedious. A useful article on threads is found at: http://www.gotw.ca/publications/concurrency-ddj.htm In my view, the reason many programmers argue vehemently against threads is a combination of several factors *all their early programs were single threaded (e.g. hello_world) and so they developed the mindset of only knowing how to cope with 1 thread. *some programming styles (which are spaghetti like in nature) are torture to debug when threaded *many of the open source tools (in particular debuggers) don't handle threads well and make the whole code&fix process too hard However, ptlib and opal are coded to a high degree of quality. There are still issues (device plugins) but these are getting fewer and fewer. Given the nature of voip and how voip works, I don't think any other model would work. Remember that opal is a library, and is used by people making hundreds of simultaneous calls. If you do propose a different way of doing things, will Hey! Have I said it's something wrong with threads? I have actually my background in tecknical systems, I was using threads long time before the word was used :-) I was just raising a question, and you have answered it. The PTlib alsa driver is defined as reentrant. I have no problems with this, once I understand it (it might be useful to document this fact in the PSoundChannel interface, I doubt I'm the only one which will stumble into this). But there *are* problems. A well behaved alsa driver should work better aganist pulse, other does. The hw buffer is way to large, 100 ms latency instead of ~50. No statistics. No rebuffering. But you have convinced on one, important point: it should be possible to enhance the driver with a set of smaller patches instead of a major rewrite. Such things are always easier. And I have absolutely no intention to look under the hood in the opal framwork. I just found Andreas' posting, and realized that I had some odd experience in alsa which might be useful. And after looking into this, I still feel that a better alsa interface in Ekiga is really important to get better latency and quality, both of which are crucial in a voip context. Or? BTW, are you the one which have an overall understanding the complete buffering scheme in Ekiga? --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, On Wed, 25 Feb 2009, Alec Leamas wrote: Hi :-) Thanks for this info! As you state, this should work as long as they are instantiated in a proper way. And it's simple just to add some assertions to make sure that this is indeed the case. I still don't get why the device pointers needs locking. Is the overall Ekiga design such as there are several threads writing concurrently? Or is this a general requirement for the driver, for other scenarios the Ekiga? In other words , is the PTlib alsa driver defined as reentrant? yes, the ptlib alsa driver needs to be reentrant. One thread could attempt to close the audio device while a second thread is reading/writing data from/to the alsa system. It is not the overall Ekiga design that sets the requirment for coping with multiple threads - it is a the PTLib/OPAL design that sets the requirement for coping with multiple threads. The discussion topic of threads and too many threads and so on has occuppied many hours at conferences, and many emails, and is slightly tedious. A useful article on threads is found at: http://www.gotw.ca/publications/concurrency-ddj.htm In my view, the reason many programmers argue vehemently against threads is a combination of several factors *all their early programs were single threaded (e.g. hello_world) and so they developed the mindset of only knowing how to cope with 1 thread. *some programming styles (which are spaghetti like in nature) are torture to debug when threaded *many of the open source tools (in particular debuggers) don't handle threads well and make the whole code&fix process too hard However, ptlib and opal are coded to a high degree of quality. There are still issues (device plugins) but these are getting fewer and fewer. Given the nature of voip and how voip works, I don't think any other model would work. Remember that opal is a library, and is used by people making hundreds of simultaneous calls. If you do propose a different way of doing things, will the new architecture cope with being scaled up? Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, >>> - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? This mutex is important, and should not syncrhonize the play&record threads. There are two PSoundChannel class instances active during a call. One for play. One for record. These PSoundChannel class instances are seperate, and have seperately opened connections to the sound_alsa plugin. Consequently, the mutex you refer to is not syncrhonising access to play&record. The mutex is locking access to play variables (device pointers) + play A different mutex instance is locking access to write variables (device pointers) + write. == Now, if the same PSoundChannel instance is used for play and record - (which can be achieved by bad application writing) then you have an application coding problem. I assume Ekiga does not have this issue. = Hi :-) Thanks for this info! As you state, this should work as long as they are instantiated in a proper way. And it's simple just to add some assertions to make sure that this is indeed the case. I still don't get why the device pointers needs locking. Is the overall Ekiga design such as there are several threads writing concurrently? Or is this a general requirement for the driver, for other scenarios the Ekiga? In other words , is the PTlib alsa driver defined as reentrant? --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, >>> - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? This mutex is important, and should not syncrhonize the play&record threads. There are two PSoundChannel class instances active during a call. One for play. One for record. These PSoundChannel class instances are seperate, and have seperately opened connections to the sound_alsa plugin. Consequently, the mutex you refer to is not syncrhonising access to play&record. The mutex is locking access to play variables (device pointers) + play A different mutex instance is locking access to write variables (device pointers) + write. == Now, if the same PSoundChannel instance is used for play and record - (which can be achieved by bad application writing) then you have an application coding problem. I assume Ekiga does not have this issue. = to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. Agreed. Derek. On Tue, 24 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, Hi :-) Have you checked the bugzilla bug? There's some more meat on the bones (or however you prefer to say it down there ;-) On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? It's not just a question of testing. This kind of problem must be handled by careful reading of code, to test all conditions possible when there are concurrent threads is not that simple. I think what should be done is to separate the recording and playback threads into separate objects, thus letting the compiler check that there are no critical zones. I also think the whole idea of a single "channel" must be interpreted as a facade for two more or less independent streams . They should not really share any data. But of course they share a lot of behaviour. - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? Well, the basic thing is a separate thread feeding alsa started when alsa is started. The write routine just drops it's buffer to the thread through some kind of thread-safe mechanism, being blocked if there is no space in (a small) buffer. The thread is just waiting for alsa (snd:_pcm_wait). When started it normally transfers data from upstream (write), rebuffering as necessary if there is nothing else to send. In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlib&opal (libraries that are crucial to this project) OK, unless you provoke you don't get an answer... I actually share your opinion :-) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? But we have 100 ms of hw buffer, roughly twice the size of other VOIP applications. There are open issues about the overall design, threads, objects etc. There are no quality metrics, we have no idea about things like bytes transferred, hard errors, soft errors, buffer usage etc. And Andreas' logs shows that the driver does not deliver data as expected. I don't want to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. As I said, take a look at the bug, there are some more details, despite the horrible formatting. And bear in mind that I'm certainly wrong from time to time. And that English isn't my native language, the nuances are a bit bit, well, rough now and then :-) Derek. --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Derek Smithies wrote: Hi, Hi :-) Have you checked the bugzilla bug? There's some more meat on the bones (or however you prefer to say it down there ;-) On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? It's not just a question of testing. This kind of problem must be handled by careful reading of code, to test all conditions possible when there are concurrent threads is not that simple. I think what should be done is to separate the recording and playback threads into separate objects, thus letting the compiler check that there are no critical zones. I also think the whole idea of a single "channel" must be interpreted as a facade for two more or less independent streams . They should not really share any data. But of course they share a lot of behaviour. - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? Well, the basic thing is a separate thread feeding alsa started when alsa is started. The write routine just drops it's buffer to the thread through some kind of thread-safe mechanism, being blocked if there is no space in (a small) buffer. The thread is just waiting for alsa (snd:_pcm_wait). When started it normally transfers data from upstream (write), rebuffering as necessary if there is nothing else to send. In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlib&opal (libraries that are crucial to this project) OK, unless you provoke you don't get an answer... I actually share your opinion :-) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? But we have 100 ms of hw buffer, roughly twice the size of other VOIP applications. There are open issues about the overall design, threads, objects etc. There are no quality metrics, we have no idea about things like bytes transferred, hard errors, soft errors, buffer usage etc. And Andreas' logs shows that the driver does not deliver data as expected. I don't want to blame anyone or so, but I think we must face the fact that there *are* problems, some of them requiring more than a point fix. As I said, take a look at the bug, there are some more details, despite the horrible formatting. And bear in mind that I'm certainly wrong from time to time. And that English isn't my native language, the nuances are a bit bit, well, rough now and then :-) Derek. --alec ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] PTLIB alsa plugin status
Hi, On Tue, 24 Feb 2009, Alec Leamas wrote: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. Yes - can someone test that ptlib alsa plugin works ok with this mutex removed?? - There is no rebuffering support. This means data underruns sounds worse than necessary. What is required to do rebuffering? Any code suggestions? In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. It is worth it. Alsa will be around for a long time. This is an opportunity for Ekiga people to contribute back to ptlib&opal (libraries that are crucial to this project) As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... The current alsa code works mostly.. it is close.. If there was some usable docs at alsa to explain what is not good, that would help. Anyone able to work out what is actually wrong in the alsa plugin? Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@indranet.co.nz ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] PTLIB alsa plugin status
I made a short review of the read/write code in the PTLIB alsa plugin yesterday. In short: - Playback and record thread are synchronized in a way that forces the two streams to wait for each others I/O operations. - There is no rebuffering support. This means data underruns sounds worse than necessary. - Various minor remarks. I've filed a bug against ekiga with some more details : http://bugzilla.gnome.org/show_bug.cgi?id=572953 (pls don't file a bug on the formatting of the attachment...). In my opinion, it's not really worth to put much work on using the current alsa plugin. As long as it works, don't touch it... until it get's fixed in a proper way, possibly by using a pulse plugin instead. As for the latency discussion about alsa vs pulse: This review shows that anything will be much better than current alsa code... --a ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
