* VOIP xrun problem @ 2012-10-22 20:40 Jamey Drennan [not found] ` <5085B04E.8040507@faberman.de> 0 siblings, 1 reply; 7+ messages in thread From: Jamey Drennan @ 2012-10-22 20:40 UTC (permalink / raw) To: alsa-devel A quick background: I'm developing a VOIP program for an embedded system. In the first phase of the program everything was event driven. Basically ask ALSA for samples, encode them, and send them via UDP to the connected client. On the other end, receive the packet, decode, play the samples. After setting the correct value for the start_threshold function everything worked great no xruns at all. Now in the second phase, events are timed due to specification requirements. The same Alsa setup code is used yet xruns (mostly underruns) are all over the place. The underruns are periodic and can be reduced by increasing the period size and number of periods (this also increases the latency obviously and is undersirable) but never removed completely. My question is how to reduce/remove the xruns. I am not currently at a point where installing a real-time OS or patching to get these features is possible. Also, when aplay/arecord is run on the system, no xruns occur. Finally, the CPU is not being overloaded, actually in the second phase the CPU usage is much less. Any help/suggestions are greatly appreciated. Thanks in advance! ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <5085B04E.8040507@faberman.de>]
* Re: VOIP xrun problem [not found] ` <5085B04E.8040507@faberman.de> @ 2012-10-22 20:56 ` Jamey Drennan 2012-10-23 6:35 ` Clemens Ladisch 0 siblings, 1 reply; 7+ messages in thread From: Jamey Drennan @ 2012-10-22 20:56 UTC (permalink / raw) To: Florian Faber; +Cc: alsa-devel Maybe I don't quite understand your question but I use RTP (oRTP library) to manage the sending/receiving of the audio streams. On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber@faberman.de> wrote: > On 10/22/12 22:40, Jamey Drennan wrote: > > Now in the second phase, events are timed due to specification > > requirements. The same Alsa setup code is used yet xruns (mostly > > underruns) are all over the place. The underruns are periodic and can be > > reduced by increasing the period size and number of periods (this also > > increases the latency obviously and is undersirable) but never removed > > completely. > > > > My question is how to reduce/remove the xruns. > > How do you synchronize the streams? You will either have to synchronize > the media clocks or do some sort of SRC. > > > Flo > -- > Machines can do the work, so people have time to think. > public key B3B9226C x-hkp://wwwkeys.eu.pgp.net > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VOIP xrun problem 2012-10-22 20:56 ` Jamey Drennan @ 2012-10-23 6:35 ` Clemens Ladisch 2012-10-23 15:00 ` Jamey Drennan 0 siblings, 1 reply; 7+ messages in thread From: Clemens Ladisch @ 2012-10-23 6:35 UTC (permalink / raw) To: Jamey Drennan; +Cc: Florian Faber, alsa-devel (quoting fixed; please don't top-post) Jamey Drennan wrote: > On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber@faberman.de> wrote: >> How do you synchronize the streams? You will either have to synchronize >> the media clocks or do some sort of SRC. > > Maybe I don't quite understand your question but I use RTP (oRTP library) > to manage the sending/receiving of the audio streams. So the RTP stream is synchronized to the sender's clock. How do you handle the differences between the stream's clock and the playback device's clock? Regards, Clemens ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VOIP xrun problem 2012-10-23 6:35 ` Clemens Ladisch @ 2012-10-23 15:00 ` Jamey Drennan 2012-10-23 15:10 ` Clemens Ladisch 2012-10-23 19:03 ` Jamey Drennan 0 siblings, 2 replies; 7+ messages in thread From: Jamey Drennan @ 2012-10-23 15:00 UTC (permalink / raw) To: alsa-devel On Tue, Oct 23, 2012 at 2:35 AM, Clemens Ladisch <clemens@ladisch.de> wrote: > (quoting fixed; please don't top-post) > Jamey Drennan wrote: > > On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber@faberman.de> > wrote: > >> How do you synchronize the streams? You will either have to synchronize > >> the media clocks or do some sort of SRC. > > > > Maybe I don't quite understand your question but I use RTP (oRTP library) > > to manage the sending/receiving of the audio streams. > > So the RTP stream is synchronized to the sender's clock. > How do you handle the differences between the stream's clock and > the playback device's clock? > > > Regards, > Clemens > The client and server negotiate the connection parameters including packet interval, size, audio format, and rate. The rtp library ensures that the packets arrive on time and accounts for initial time differences. Maybe the timestamps of the stream packets aren't enough to keep the two clocks synchronized(or a frame is the same regardless if the two devices are set up the same)? In testing, the two clocks are one and the same since I am running the client and server on the same device. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VOIP xrun problem 2012-10-23 15:00 ` Jamey Drennan @ 2012-10-23 15:10 ` Clemens Ladisch 2012-10-23 19:03 ` Jamey Drennan 1 sibling, 0 replies; 7+ messages in thread From: Clemens Ladisch @ 2012-10-23 15:10 UTC (permalink / raw) To: alsa-devel Jamey Drennan wrote: > On Tue, Oct 23, 2012 at 2:35 AM, Clemens Ladisch <clemens@ladisch.de> wrote: >> So the RTP stream is synchronized to the sender's clock. >> How do you handle the differences between the stream's clock and >> the playback device's clock? > > The client and server negotiate the connection parameters including packet > interval, size, audio format, and rate. The rtp library ensures that the > packets arrive on time and accounts for initial time differences. Maybe > the timestamps of the stream packets aren't enough to keep the two clocks > synchronized(or a frame is the same regardless if the two devices are set > up the same)? The sender's and receiver's clocks are determined by the crystals soldered onto their sound cards. You can try to configure them for the same nominal sample rate, but you cannot avoid that they run fast or slow relative to each other by some fraction of a percent. > In testing, the two clocks are one and the same since I am > running the client and server on the same device. So the problem shows up even when testing? Regards, Clemens ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VOIP xrun problem 2012-10-23 15:00 ` Jamey Drennan 2012-10-23 15:10 ` Clemens Ladisch @ 2012-10-23 19:03 ` Jamey Drennan 2012-10-24 16:21 ` Jamey Drennan 1 sibling, 1 reply; 7+ messages in thread From: Jamey Drennan @ 2012-10-23 19:03 UTC (permalink / raw) To: alsa-devel On Tue, Oct 23, 2012 at 11:00 AM, Jamey Drennan <jamey.drennan@gmail.com>wrote: > On Tue, Oct 23, 2012 at 2:35 AM, Clemens Ladisch <clemens@ladisch.de>wrote: > >> (quoting fixed; please don't top-post) >> Jamey Drennan wrote: >> > On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber@faberman.de> >> wrote: >> >> How do you synchronize the streams? You will either have to synchronize >> >> the media clocks or do some sort of SRC. >> > >> > Maybe I don't quite understand your question but I use RTP (oRTP >> library) >> > to manage the sending/receiving of the audio streams. >> >> So the RTP stream is synchronized to the sender's clock. >> How do you handle the differences between the stream's clock and >> the playback device's clock? >> >> >> Regards, >> Clemens >> > > The client and server negotiate the connection parameters including packet > interval, size, audio format, and rate. The rtp library ensures that the > packets arrive on time and accounts for initial time differences. Maybe > the timestamps of the stream packets aren't enough to keep the two clocks > synchronized(or a frame is the same regardless if the two devices are set > up the same)? In testing, the two clocks are one and the same since I am > running the client and server on the same device. > So the problem shows up even when testing? Yes the problem is occurring in testing as well. An interesting fix of sorts that I just found is, if I adjust my playback function to play slightly less than a whole packet, the playback function gets called twice and the underrun goes away. This makes sense in a way because now I'm essentially giving the ring buffer twice the amount of data than it was getting before. The odd thing is there are no noticeable sound artifacts like echoing or fuzz as I would expect. I agree that is definitely a timing/clock issue and I appreciate the help. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VOIP xrun problem 2012-10-23 19:03 ` Jamey Drennan @ 2012-10-24 16:21 ` Jamey Drennan 0 siblings, 0 replies; 7+ messages in thread From: Jamey Drennan @ 2012-10-24 16:21 UTC (permalink / raw) To: alsa-devel On Tue, Oct 23, 2012 at 3:03 PM, Jamey Drennan <jamey.drennan@gmail.com>wrote: > On Tue, Oct 23, 2012 at 11:00 AM, Jamey Drennan <jamey.drennan@gmail.com>wrote: > >> On Tue, Oct 23, 2012 at 2:35 AM, Clemens Ladisch <clemens@ladisch.de>wrote: >> >>> (quoting fixed; please don't top-post) >>> Jamey Drennan wrote: >>> > On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber@faberman.de> >>> wrote: >>> >> How do you synchronize the streams? You will either have to >>> synchronize >>> >> the media clocks or do some sort of SRC. >>> > >>> > Maybe I don't quite understand your question but I use RTP (oRTP >>> library) >>> > to manage the sending/receiving of the audio streams. >>> >>> So the RTP stream is synchronized to the sender's clock. >>> How do you handle the differences between the stream's clock and >>> the playback device's clock? >>> >>> >>> Regards, >>> Clemens >>> >> >> The client and server negotiate the connection parameters including >> packet interval, size, audio format, and rate. The rtp library ensures >> that the packets arrive on time and accounts for initial time differences. >> Maybe the timestamps of the stream packets aren't enough to keep the two >> clocks synchronized(or a frame is the same regardless if the two devices >> are set up the same)? In testing, the two clocks are one and the same >> since I am running the client and server on the same device. > > > > So the problem shows up even when testing? > > Yes the problem is occurring in testing as well. > An interesting fix of sorts that I just found is, if I adjust my playback > function to play slightly less than a whole packet, the playback function > gets called twice and the underrun goes away. This makes sense in a way > because now I'm essentially giving the ring buffer twice the amount of data > than it was getting before. The odd thing is there are no noticeable sound > artifacts like echoing or fuzz as I would expect. > I agree that is definitely a timing/clock issue and I appreciate the > help. > I think I finally isolated the problem. The specification that I'm working under defines when the updates for the various streams should happen. Checking the timing on these updates revealed that they are occuring slower than anticipated. The underruns makes sense since I'm only ever sending enough data for the intended schedule as opposed to how much time actually transpired. Thanks again for the help! (Sorry about the formatting errors, my e-mail client doesn't appear to handle this well). ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-24 16:21 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-22 20:40 VOIP xrun problem Jamey Drennan [not found] ` <5085B04E.8040507@faberman.de> 2012-10-22 20:56 ` Jamey Drennan 2012-10-23 6:35 ` Clemens Ladisch 2012-10-23 15:00 ` Jamey Drennan 2012-10-23 15:10 ` Clemens Ladisch 2012-10-23 19:03 ` Jamey Drennan 2012-10-24 16:21 ` Jamey Drennan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.