Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Derek Smithies wrote: Hi, Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! It is PTLib which contains the code to read from alsa. Surely, the ideal is not to go via ALSA, but have ptlib directly talk to pulse. Thus, we need to write a ptlib plugin for pulse audio. We know how ptlib plugins work. There are example plugins for alsa, esd, oss, sunaudio. The big question is writing a plugin for pulse. What is involved in writing code that talks directly to pulse ? Anyone know example code, or of the pulse api docs? Please don't refer me to docs which say just use alsa code. We are using alsa code, and that is why we are having this issue. Derek. I think you are right. For the reasons you mention, but also because the current alsa plugin is seriously flawed I made a short review very late yesterday. Among other things it's synchronized in a way that forces playback and record to wait for each others' I/O operations(!) With this said, I don't (yet) see any problems in understanding and using the external interface. These problems are within the alsa plugin. So: with limited resources we have a choice to either fix (i. e., major rewrite of) current alsa plugin, or make a pulse plugin. The latter is most likely easier. But then we leave platforms without pulse in the dark ages. So question is: do we need a working alsa plugin if we have a pulse one? Anyone? (let's take silence as a no :-) ) What disturbs me a little is the way the plugin interface seems to be, at least from the alsa example. Question is if there is a way to arrange event-driven I/O - current code is strictly polled. OTOH, we can live with that, for sure. But there might* be other hooks in the plugin interface not used today... we might need to backwards-engineer some docs... possibly expanding the plugin interface in a backwards-compatible way There is good pulse doc's on their website e. g., http://0pointer.de/lennart/projects/pulseaudio/doxygen/ ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
On Tue, 24 Feb 2009, Alec Leamas wrote: Derek Smithies wrote: Hi, Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! It is PTLib which contains the code to read from alsa. Surely, the ideal is not to go via ALSA, but have ptlib directly talk to pulse. Thus, we need to write a ptlib plugin for pulse audio. We know how ptlib plugins work. There are example plugins for alsa, esd, oss, sunaudio. The big question is writing a plugin for pulse. What is involved in writing code that talks directly to pulse ? Anyone know example code, or of the pulse api docs? Please don't refer me to docs which say just use alsa code. We are using alsa code, and that is why we are having this issue. Derek. I think you are right. For the reasons you mention, but also because the current alsa plugin is seriously flawed I made a short review very late yesterday. Among other things it's synchronized in a way that forces playback and record to wait for each others' I/O operations(!) Yes - I am aware of this mutex. Have you tried it with this synchronizing mutex removed? That mutex has been there since the the plugin was written. With this said, I don't (yet) see any problems in understanding and using the external interface. These problems are within the alsa plugin. So: with limited resources we have a choice to either fix (i. e., major rewrite of) current alsa plugin, or make a pulse plugin. What is there to rewrite? There are only a few things that are possibly wrong - the synchronising mutex and what else? It is, as you say, copied from the alsa example docs The latter is most likely easier. Not really... But then we leave platforms without pulse in the dark ages. So question is: do we need a working alsa plugin if we have a pulse one? Anyone? (let's take silence as a no :-) ) A working alsa plugin is a requirement. There may only be 5 % of users using alsa, but they will scream loud and long if it does not work for them. Some x11 window environments don't have pulse audio in them. So you need pulse and alsa plugins. What disturbs me a little is the way the plugin interface seems to be, at least from the alsa example. Question is if there is a way to arrange event-driven I/O - current code is strictly polled. The current code is arranged so that *the application writes/reads a block of data to/from the sound device. *this process is timed by the sound device so that the write/read takes as long as the framesize of the codec. Thus, for GSM (20ms frame) the write/read takes 20ms. It is the sound device that times the sending of UDP packets to the remote endpoint. Software timers are very unreliable (in comparison to hardware timers, where the board/driver determines the read time as being exactly 20ms) Suppose we have 3 GSM frames in each UDP packet. This means that every 60ms (silence detection disabled) a UDP packet is sent to the remote node. To do the timing, there is a read of 320 bytes, which takes 20ms, encode of audio frame read of 320 bytes, which takes 20ms, encode of audio frame read of 320 bytes, which takes 20ms, encode of audio frame and the three encoded audio frames are placed in a UDP packet which is sent to the remote host. OTOH, we can live with that, for sure. But there might* be other hooks in the plugin interface not used today... we might need to backwards-engineer some docs... possibly expanding the plugin interface in a backwards-compatible way Sounds pretty hard way to do things.. I think the PTlib developers won't be happy with expansion of the plugin interface.. There is good pulse doc's on their website e. g., http://0pointer.de/lennart/projects/pulseaudio/doxygen/ Thanks for this. It is a more useful set of documentation than when I last looked for pulse-doc like things. -- 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] A comparison ALSA-PULSE ( long)
Andrea wrote: Alec Leamas wrote: Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min: 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1445068800 I attach more output. What you have seen so far was the log when ekiga plays the ring tone (by far the most damaged sound). When running the echo test the setup is different stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 1 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 800 period_size : 160 period_time : 2 tstamp_mode : NONE period_step : 1 avail_min: 160 period_event : 0 start_threshold : 1 stop_threshold : 800 silence_threshold: 0 silence_size : 0 boundary : 1677721600 And I cannot see any underrun at all. My echo test uses PCMA. It is possible that with a better codec (i.e. higher rate that 8000), we see them again. Don't really know how to test. I would say that the quality of the echo test with or without pulse is the same (but being only 8000 Hz, it is already not perfect and more difficult to judge). All my tests so far have been run in debug, so the speed of ekiga/opal/ptlib is already lower the release. The quality of the ring tone is though more or less the same. I will try to rerun everything in release. I have 2 points 1) Is the following true: ekiga-pulse gives bad audio quality because there are underruns. So, if for some connection there are no underruns (e.g. my echo test) then, the quality is not expected to be lower than alsa-direct, and we should not complain about pulse. Yes. And, whatever the problems are, I don't really think it's pulse. I think it's a problem how we handle alsa which is just not that visible today. 2) If underruns are (the) evil (or at least the biggest problem), then it would be good to print some indication of how close to the underrun we are. Does alsa provide that? Is it already part of my log? Yes, in the max_avail, see below. But bear in mind that it's not only a question about if underruns happens, it's also a question how they are handled. Actually, a correct working upper layer (opal...) should never allow alsa underruns, it should rebuffer (send previous data) if nothing else is available. It's sounds much better than an actual underrun. I still have not fully understood your comments about the values printed in the log. I need to get familiar with the terminology. And I have not yet checked for overruns when reading from the microphone. Andrea OK, as long you don't feel I occupy your territory, I'll make a try. After some reading my memories are coming back. But don't take what I say for granted, this *is* complicated. And if anyone who really knows alsa could review this, I would be more than happy... First of all: Alsa is basically, in all interfaces, concerned with frames. A frame is what the hardware handles in parallel. So in a mono stream, a frame is the same as a sample. In a stereo stream, a frame is two samples. The sample is S16_LE (signed 16 bit litte endian) i e, two bytes. So a frame is four bytes when sending the sound (stereo) and two bytes when talking as above (one channel, mono). The next entity is a period. A period is (in this context) a chunk of data transferred from user space to the alsa drivers' hw ringbuffer. The ringbuffer is normally an even number of periods. In the case above the period size is 160 frames. Since a frame is a sample ( mono), it's actually 320 bytes. But it's better to stick to frames, that's what alsa is all about. Last we have the hw bufffer. It's actually a ring buffer, where the application stores data, and the driver/interrupt routines fetches it and transfers it to the sound card. The overrun/underrun condtions is really what happens when the two ringbuffer pointers becomes equal, The period size is 160 frames. 1 frame takes 1/8000 seconds = 1000/8000 ms = period time 160/8 ms = 20 ms. The buffer above is actually 800/8 ms = 100 ms. This is quite a large buffer, with added network latency it might be to large. A goal is to keep the overall latency below 150 ms. The avail reflects the number of frames free to write in the hw buffer. When the buffer is full it's 0. When it's empty, it's the buffer size. The normal behaviour is that the application writes a period as soon as avail is = 1 period. Sending routines should somehow (blocking I/O, event-driven) be sure that avail is indeed = 1 period before it writes
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Alec Leamas leamas.a...@gmail.com writes: When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! Mark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Mark T.B. Carroll wrote: Alec Leamas leamas.a...@gmail.com writes: When looking for quality info (underruns, other errors etc) it's really a question of what opal provides. It's there all errors are handled, and hopefully logged somehow. *If* opal is the lib handling alsa, which is just a guess from my side. Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! Indeed., grep tells it all. I have no more understanding than that the alsa functions are present there, and nowhere else. ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)
Hi, Perhaps it's PTLib underneath it? I really don't know, I'm just throwing the idea out there! It is PTLib which contains the code to read from alsa. Surely, the ideal is not to go via ALSA, but have ptlib directly talk to pulse. Thus, we need to write a ptlib plugin for pulse audio. We know how ptlib plugins work. There are example plugins for alsa, esd, oss, sunaudio. The big question is writing a plugin for pulse. What is involved in writing code that talks directly to pulse ? Anyone know example code, or of the pulse api docs? Please don't refer me to docs which say just use alsa code. We are using alsa code, and that is why we are having this issue. 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
