[sip-comm-dev] Portaudio linux


#1

Hi all and Werner,

there was some major improvements lately in the alsa backend in
portaudio. I've just compiled latest version and commit it.
If you experience any problems please report.

And Werner can you again test that situation with buffer length you
had and the degrading of the sound quality(the situation with dmix,
for which you provided a patch), does it happen with these binaries ?

Thanks
damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Damian,

thanks for taking care of this. I followed the discussions on the
portaudio list and saw many improvements. Of course I'll check
the new stuff with my devices, without pulseaudio (using ALSA devices
directly) and report the results on the list.

Regards,
Werner

···

Am 04.06.2010 08:58, schrieb Damian Minkov:

Hi all and Werner,

there was some major improvements lately in the alsa backend in
portaudio. I've just compiled latest version and commit it.
If you experience any problems please report.

And Werner can you again test that situation with buffer length you
had and the degrading of the sound quality(the situation with dmix,
for which you provided a patch), does it happen with these binaries ?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

···

Am 04.06.2010 09:31, schrieb Werner Dittmann:

Damian,

thanks for taking care of this. I followed the discussions on the
portaudio list and saw many improvements. Of course I'll check
the new stuff with my devices, without pulseaudio (using ALSA devices
directly) and report the results on the list.

Regards,
Werner

Am 04.06.2010 08:58, schrieb Damian Minkov:

Hi all and Werner,

there was some major improvements lately in the alsa backend in
portaudio. I've just compiled latest version and commit it.
If you experience any problems please report.

And Werner can you again test that situation with buffer length you
had and the degrading of the sound quality(the situation with dmix,
for which you provided a patch), does it happen with these binaries ?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi,

can you test with latest binaries that I've just updated (latest
didn't have your patch pa_linux_alsa.c-by-Werner.patch :frowning: ).
I've also have found another problem under linux system, and have some
patch for it but as it may affect other operating system I haven't
commit it. And we must also discuss this with other devs, as I think
and we must created and one more thread for receiving and sending so
we can also change threads priorities (a thing I've seen in jmf
threads).
The other problem can easily be seen when you make a dump and packets
that come out and in are at a groups of 10 or more at once. My opinion
is that threads reading and writing rtp data which we have created,
read or write as long as they can and don't give time for the other
threads (no good thread context switching or something like that). If
you put a simple sleep(1) (for 1 ms) after every read and write this
way you give time for the other thread to switch and send or receive.
This way the dump will show how those groups of packets will become to
2,3 or 4 packets and for me this way my outgoing audio stream is
significantly better, this also affects incoming media quality to
better.

Thanks
damencho

···

On Sun, Jun 6, 2010 at 4:09 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

Am 04.06.2010 09:31, schrieb Werner Dittmann:

Damian,

thanks for taking care of this. I followed the discussions on the
portaudio list and saw many improvements. Of course I'll check
the new stuff with my devices, without pulseaudio (using ALSA devices
directly) and report the results on the list.

Regards,
Werner

Am 04.06.2010 08:58, schrieb Damian Minkov:

Hi all and Werner,

there was some major improvements lately in the alsa backend in
portaudio. I've just compiled latest version and commit it.
If you experience any problems please report.

And Werner can you again test that situation with buffer length you
had and the degrading of the sound quality(the situation with dmix,
for which you provided a patch), does it happen with these binaries ?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Damian,

Hi,

can you test with latest binaries that I've just updated (latest
didn't have your patch pa_linux_alsa.c-by-Werner.patch :frowning: ).

I thought that the latest portaudio addressed these problems as well.
But I'll give it a try, of course :slight_smile: .

I've also have found another problem under linux system, and have some
patch for it but as it may affect other operating system I haven't
commit it. And we must also discuss this with other devs, as I think
and we must created and one more thread for receiving and sending so
we can also change threads priorities (a thing I've seen in jmf
threads).

Aren't input and output already in own threads?

The other problem can easily be seen when you make a dump and packets
that come out and in are at a groups of 10 or more at once. My opinion
is that threads reading and writing rtp data which we have created,
read or write as long as they can and don't give time for the other
threads (no good thread context switching or something like that).

Hmmmm, at least the input (capture) thread should be blocked by the
operating system for about 20ms because this is the time that's
required to read the samples. Thus this shouldn't go in a "tight loop"
and reading 10 packets at once and send them (this would account
for 200ms of audio data).

If
you put a simple sleep(1) (for 1 ms) after every read and write this
way you give time for the other thread to switch and send or receive.
This way the dump will show how those groups of packets will become to
2,3 or 4 packets and for me this way my outgoing audio stream is
significantly better, this also affects incoming media quality to
better.

Instead of doing a 1ms wait - would a simple yield() call do it as well?
I've seen this in the desktop streaming implementation: it calls yield()
in case the desktop capture takes longer the the refresh rate (100ms) and
it seems to work.

Regards,
Werner

···

Am 07.06.2010 17:31, schrieb Damian Minkov:

Thanks
damencho

On Sun, Jun 6, 2010 at 4:09 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Damian,

the tests with the latest portaudio binary went well. No blocking
input (capture) thread, sound quality is ok, both with dmix ALSA
device as well as with default device. But we always should use
dmix to enable parallel output of audio (voice and notification
audio).

Regarding "RTP packet groups": I used iptel's echo test to check
out how my system behaves. Iptel echo service sends RTP packet
every 20ms, very regular timing (like a swiss watch :slight_smile: ). SC on
my systems sends 2, sometimes 3 RTP packets with just 1ms between
the packets, then pauses for 40ms or 60ms, sends 2 packets with
just 1ms between packets, pauses 40ms, and so on. For this test
I just replaced the portaudio native binary with your latest
version. I'll try a yield() call after a send packet and give you
feedback.

Regards,
Werner

···

Am 07.06.2010 19:23, schrieb Werner Dittmann:

Damian,

Am 07.06.2010 17:31, schrieb Damian Minkov:

Hi,

can you test with latest binaries that I've just updated (latest
didn't have your patch pa_linux_alsa.c-by-Werner.patch :frowning: ).

I thought that the latest portaudio addressed these problems as well.
But I'll give it a try, of course :slight_smile: .

I've also have found another problem under linux system, and have some
patch for it but as it may affect other operating system I haven't
commit it. And we must also discuss this with other devs, as I think
and we must created and one more thread for receiving and sending so
we can also change threads priorities (a thing I've seen in jmf
threads).

Aren't input and output already in own threads?

The other problem can easily be seen when you make a dump and packets
that come out and in are at a groups of 10 or more at once. My opinion
is that threads reading and writing rtp data which we have created,
read or write as long as they can and don't give time for the other
threads (no good thread context switching or something like that).

Hmmmm, at least the input (capture) thread should be blocked by the
operating system for about 20ms because this is the time that's
required to read the samples. Thus this shouldn't go in a "tight loop"
and reading 10 packets at once and send them (this would account
for 200ms of audio data).

If
you put a simple sleep(1) (for 1 ms) after every read and write this
way you give time for the other thread to switch and send or receive.
This way the dump will show how those groups of packets will become to
2,3 or 4 packets and for me this way my outgoing audio stream is
significantly better, this also affects incoming media quality to
better.

Instead of doing a 1ms wait - would a simple yield() call do it as well?
I've seen this in the desktop streaming implementation: it calls yield()
in case the desktop capture takes longer the the refresh rate (100ms) and
it seems to work.

Regards,
Werner

Thanks
damencho

On Sun, Jun 6, 2010 at 4:09 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hey Werner,

Do you get better results with other apps? We've been seeing this
"burst" behaviour with some Linux Wi-Fi drivers.

Emil

На 07.06.10 19:41, Werner Dittmann написа:

···

Hi Damian,

the tests with the latest portaudio binary went well. No blocking
input (capture) thread, sound quality is ok, both with dmix ALSA
device as well as with default device. But we always should use
dmix to enable parallel output of audio (voice and notification
audio).

Regarding "RTP packet groups": I used iptel's echo test to check
out how my system behaves. Iptel echo service sends RTP packet
every 20ms, very regular timing (like a swiss watch :slight_smile: ). SC on
my systems sends 2, sometimes 3 RTP packets with just 1ms between
the packets, then pauses for 40ms or 60ms, sends 2 packets with
just 1ms between packets, pauses 40ms, and so on. For this test
I just replaced the portaudio native binary with your latest
version. I'll try a yield() call after a send packet and give you
feedback.

Regards,
Werner

Am 07.06.2010 19:23, schrieb Werner Dittmann:

Damian,

Am 07.06.2010 17:31, schrieb Damian Minkov:

Hi,

can you test with latest binaries that I've just updated (latest
didn't have your patch pa_linux_alsa.c-by-Werner.patch :frowning: ).

I thought that the latest portaudio addressed these problems as well.
But I'll give it a try, of course :slight_smile: .

I've also have found another problem under linux system, and have some
patch for it but as it may affect other operating system I haven't
commit it. And we must also discuss this with other devs, as I think
and we must created and one more thread for receiving and sending so
we can also change threads priorities (a thing I've seen in jmf
threads).

Aren't input and output already in own threads?

The other problem can easily be seen when you make a dump and packets
that come out and in are at a groups of 10 or more at once. My opinion
is that threads reading and writing rtp data which we have created,
read or write as long as they can and don't give time for the other
threads (no good thread context switching or something like that).

Hmmmm, at least the input (capture) thread should be blocked by the
operating system for about 20ms because this is the time that's
required to read the samples. Thus this shouldn't go in a "tight loop"
and reading 10 packets at once and send them (this would account
for 200ms of audio data).

If
you put a simple sleep(1) (for 1 ms) after every read and write this
way you give time for the other thread to switch and send or receive.
This way the dump will show how those groups of packets will become to
2,3 or 4 packets and for me this way my outgoing audio stream is
significantly better, this also affects incoming media quality to
better.

Instead of doing a 1ms wait - would a simple yield() call do it as well?
I've seen this in the desktop streaming implementation: it calls yield()
in case the desktop capture takes longer the the refresh rate (100ms) and
it seems to work.

Regards,
Werner

Thanks
damencho

On Sun, Jun 6, 2010 at 4:09 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi,

i missed the part with wifi, sorry. This grouping behavior is mostly
seen in wifi environment. I experienced it only once or twice when
using wired connection. Reading doesn't always spend 20ms cause there
is some buffering which for example sometimes can give you for 10 ms,
60 ms data.
About threads I mean dedicated threads only for socket manipulation.
There is something similar now for video sending, so we can provide
some sending restrictions. Internally jmf has different priorities for
different thread types. There are priorities for audio(3), network
audio(4), video(4), network video(5) and control threads(9). Currently
sending and receiving are with priority 9 (which is set from jmf),
control threads.
About yield, I've search for opinions about coping with situations
like this and there was a description about how yield works and that
you can not count on it and the recommendations where to avoid using
it where possible. In Linux if I remember right, yield behavior
drastically changed from java 1.5 to java6 and latest implementation
is that when you call yield all threads with same priority must have
some time before the thread that call yield will be given execution
time again. This can lead to worse scenarios.
Although I'm not sure about priorities, are they used for thread
switching or only for yield.

Thanks
damencho

···

On Mon, Jun 7, 2010 at 8:41 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi Damian,

the tests with the latest portaudio binary went well. No blocking
input (capture) thread, sound quality is ok, both with dmix ALSA
device as well as with default device. But we always should use
dmix to enable parallel output of audio (voice and notification
audio).

Regarding "RTP packet groups": I used iptel's echo test to check
out how my system behaves. Iptel echo service sends RTP packet
every 20ms, very regular timing (like a swiss watch :slight_smile: ). SC on
my systems sends 2, sometimes 3 RTP packets with just 1ms between
the packets, then pauses for 40ms or 60ms, sends 2 packets with
just 1ms between packets, pauses 40ms, and so on. For this test
I just replaced the portaudio native binary with your latest
version. I'll try a yield() call after a send packet and give you
feedback.

Regards,
Werner

Am 07.06.2010 19:23, schrieb Werner Dittmann:

Damian,

Am 07.06.2010 17:31, schrieb Damian Minkov:

Hi,

can you test with latest binaries that I've just updated (latest
didn't have your patch pa_linux_alsa.c-by-Werner.patch :frowning: ).

I thought that the latest portaudio addressed these problems as well.
But I'll give it a try, of course :slight_smile: .

I've also have found another problem under linux system, and have some
patch for it but as it may affect other operating system I haven't
commit it. And we must also discuss this with other devs, as I think
and we must created and one more thread for receiving and sending so
we can also change threads priorities (a thing I've seen in jmf
threads).

Aren't input and output already in own threads?

The other problem can easily be seen when you make a dump and packets
that come out and in are at a groups of 10 or more at once. My opinion
is that threads reading and writing rtp data which we have created,
read or write as long as they can and don't give time for the other
threads (no good thread context switching or something like that).

Hmmmm, at least the input (capture) thread should be blocked by the
operating system for about 20ms because this is the time that's
required to read the samples. Thus this shouldn't go in a "tight loop"
and reading 10 packets at once and send them (this would account
for 200ms of audio data).

If
you put a simple sleep(1) (for 1 ms) after every read and write this
way you give time for the other thread to switch and send or receive.
This way the dump will show how those groups of packets will become to
2,3 or 4 packets and for me this way my outgoing audio stream is
significantly better, this also affects incoming media quality to
better.

Instead of doing a 1ms wait - would a simple yield() call do it as well?
I've seen this in the desktop streaming implementation: it calls yield()
in case the desktop capture takes longer the the refresh rate (100ms) and
it seems to work.

Regards,
Werner

Thanks
damencho

On Sun, Jun 6, 2010 at 4:09 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Damian,

I did some first tests and it seems that the new portaudio lib is
not bettwre or worse than the previous version. I'm not using
pulseaudio but ALSA directly. Ican do some more tests after
iptel.org restored its fine music service.

Some of the jitters that I currently hear maybe du to network
latency (I was using another music service to get some long
playing sounds).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

···

Am 07.06.2010 21:37, schrieb Emil Ivov:

Hey Werner,

Do you get better results with other apps? We've been seeing this
"burst" behaviour with some Linux Wi-Fi drivers.

Emil

На 07.06.10 19:41, Werner Dittmann написа:

Hi Damian,

the tests with the latest portaudio binary went well. No blocking
input (capture) thread, sound quality is ok, both with dmix ALSA
device as well as with default device. But we always should use
dmix to enable parallel output of audio (voice and notification
audio).

Regarding "RTP packet groups": I used iptel's echo test to check
out how my system behaves. Iptel echo service sends RTP packet
every 20ms, very regular timing (like a swiss watch :slight_smile: ). SC on
my systems sends 2, sometimes 3 RTP packets with just 1ms between
the packets, then pauses for 40ms or 60ms, sends 2 packets with
just 1ms between packets, pauses 40ms, and so on. For this test
I just replaced the portaudio native binary with your latest
version. I'll try a yield() call after a send packet and give you
feedback.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi,

it sounds interesting, actually there is a buffering in portaudio as I
remember. That's why there is framesPerBuffer when opening stream,
they are the size of the buffers at our side. Internally there are
hostBufferSize or something like that, which are the buffers for the
alsa/pulseaudio devices.
We must check can we tweak it.

Regards
damencho

···

On Tue, Jun 8, 2010 at 8:16 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

Am 07.06.2010 21:37, schrieb Emil Ivov:

Hey Werner,

Do you get better results with other apps? We've been seeing this
"burst" behaviour with some Linux Wi-Fi drivers.

Emil

На 07.06.10 19:41, Werner Dittmann написа:

Hi Damian,

the tests with the latest portaudio binary went well. No blocking
input (capture) thread, sound quality is ok, both with dmix ALSA
device as well as with default device. But we always should use
dmix to enable parallel output of audio (voice and notification
audio).

Regarding "RTP packet groups": I used iptel's echo test to check
out how my system behaves. Iptel echo service sends RTP packet
every 20ms, very regular timing (like a swiss watch :slight_smile: ). SC on
my systems sends 2, sometimes 3 RTP packets with just 1ms between
the packets, then pauses for 40ms or 60ms, sends 2 packets with
just 1ms between packets, pauses 40ms, and so on. For this test
I just replaced the portaudio native binary with your latest
version. I'll try a yield() call after a send packet and give you
feedback.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Damian,

can you send me the latest patched sources of the pa_alsa
host adapter for portaudio, I would like to dig into this a
little bit.

I've checked Twinkle's implementation of ALSA and it is _much_
simpler than Portaudio and does not deal with this complex
buffer arithmetic etc.

IMHO Portaudio's buffer management and the way it checks and
reads the data from ALSA is very complex, to state it in a
kind way :-). PA supports MMAP reads and non-MMAP reads which
complicates matters, also it combines blocking with non-blocking
read functions and it seems to have a sort of own thread
monitoring or something similar.

Maybe we need to use a stripped-down version to make it more
reliable.

Regards,
Werner

···

Am 09.06.2010 07:45, schrieb Damian Minkov:

Hi,

it sounds interesting, actually there is a buffering in portaudio as I
remember. That's why there is framesPerBuffer when opening stream,
they are the size of the buffers at our side. Internally there are
hostBufferSize or something like that, which are the buffers for the
alsa/pulseaudio devices.
We must check can we tweak it.

Regards
damencho

On Tue, Jun 8, 2010 at 8:16 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hey Werner,

На 09.06.10 19:22, Werner Dittmann написа:

Maybe we need to use a stripped-down version to make it more
reliable.

Lubomir is currently working on a revamped audio capture and playback
layer. It's main purpose was to allow the use of wideband codecs but it
also changes the way we read and write with portaudio so you might want
to check this out first.

Besides, we have a number of issues, upcoming features, and a pending
release, so adding to this list the maintenance of a portaudio fork is
IMHO way above what we can actually handle :).

Emil

···

Regards,
Werner

Am 09.06.2010 07:45, schrieb Damian Minkov:

Hi,

it sounds interesting, actually there is a buffering in portaudio as I
remember. That's why there is framesPerBuffer when opening stream,
they are the size of the buffers at our side. Internally there are
hostBufferSize or something like that, which are the buffers for the
alsa/pulseaudio devices.
We must check can we tweak it.

Regards
damencho

On Tue, Jun 8, 2010 at 8:16 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Hi Werner,

here is the source(of the hostapi alsa) for the latest binary that is
in the trunk.

Thanks
damencho

pa_linux_alsa.zip (28.8 KB)

···

On Wed, Jun 9, 2010 at 8:22 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Damian,

can you send me the latest patched sources of the pa_alsa
host adapter for portaudio, I would like to dig into this a
little bit.

I've checked Twinkle's implementation of ALSA and it is _much_
simpler than Portaudio and does not deal with this complex
buffer arithmetic etc.

IMHO Portaudio's buffer management and the way it checks and
reads the data from ALSA is very complex, to state it in a
kind way :-). PA supports MMAP reads and non-MMAP reads which
complicates matters, also it combines blocking with non-blocking
read functions and it seems to have a sort of own thread
monitoring or something similar.

Maybe we need to use a stripped-down version to make it more
reliable.

Regards,
Werner

Am 09.06.2010 07:45, schrieb Damian Minkov:

Hi,

it sounds interesting, actually there is a buffering in portaudio as I
remember. That's why there is framesPerBuffer when opening stream,
they are the size of the buffers at our side. Internally there are
hostBufferSize or something like that, which are the buffers for the
alsa/pulseaudio devices.
We must check can we tweak it.

Regards
damencho

On Tue, Jun 8, 2010 at 8:16 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Hi Emil,

don't worry - I'm just looking into it to see if we can
improve things here without modifying PortAudio, e.g.
which device parameters to use, buffer length or alike that
we can control via API.

Using a stripped down version would be only relevant if PA
would be really instable - which it isn't.

On the other hand --- tweaking around just before releasing
of a stable version would be a real thrill :wink:

Regards,
Werner

···

Am 10.06.2010 10:18, schrieb Emil Ivov:

Hey Werner,

На 09.06.10 19:22, Werner Dittmann написа:

Maybe we need to use a stripped-down version to make it more
reliable.

Lubomir is currently working on a revamped audio capture and playback
layer. It's main purpose was to allow the use of wideband codecs but it
also changes the way we read and write with portaudio so you might want
to check this out first.

Besides, we have a number of issues, upcoming features, and a pending
release, so adding to this list the maintenance of a portaudio fork is
IMHO way above what we can actually handle :).

Emil

Regards,
Werner

Am 09.06.2010 07:45, schrieb Damian Minkov:

Hi,

it sounds interesting, actually there is a buffering in portaudio as I
remember. That's why there is framesPerBuffer when opening stream,
they are the size of the buffers at our side. Internally there are
hostBufferSize or something like that, which are the buffers for the
alsa/pulseaudio devices.
We must check can we tweak it.

Regards
damencho

On Tue, Jun 8, 2010 at 8:16 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Hi Emil, Damian,

I did some tests with another application, twinkle in this case,
to see how this behaves. Twinkle uses ALSA directly without
Portaudio wrapper. Wireshark shows that twinkle sends a RTP packet
nearly every 20ms with a jitter of 10ms +/- in some cases, maybe
due to thread switching (native pthread). Twinkle also uses
a C++ RTP stack (GNU ccRTP) implementation.

The I did some tests with SC again and traced the read of the
capture device directly after the Portaudio read. Surprise: the
packet bursts I see in wireshark when monitoring SC are triggered
by Portaudio. The trace prints show that Portaudio sometimes
returns 2 or 3 packets in a short time (3ms) after a pause of
40ms or 60ms. I don't now yet why this happens. I can't believe
that it is due to thread switching because one packet every 20ms
is rather slow. Maybe we have to look at some Portaudio internals
(buffering maybe, Portaudio initialization parameters maybe).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Damencho,

IMHO I fixed some of the portaudio latency topics. Some findings:

- the SC portaudio code in PortAudioManager.getSuggestedLatency() returns
  the value PortAudio.LATENCY_HIGH which translates to -1d. PortAudio JNI
  code translates this value into the device specific high latency, for
  my device ~46ms. This results into the 2 to 3 packet bursts on my system.
  I changed the return of "getSuggestedLatency()" to 20ms (return 0.02d) and
  now I get a packet every 20ms from PortAudio.

- Above does not work for the device "default". This device has its own idea
  about buffers, latency etc and always has a latency of 46ms for my device.

- Thus I use the device "hw:0,0" as input device, in my select box this is
  the first device with the real sound card name. Setting the environment
  variable PA_ALSA_PLUGHW to 1 forces PortAudio to use the "plughw:0,0"
  device. This is the preferred device setting.

- For output always use "dmix" or any other device that is capable of mixing
  2 output streams if the sound HW does not support mixing.

IMHO the handling of the latency parameters in PortAudio needs some rework.
The latency for Windows is set to 100ms, for example. Why this? Or does
PortAudio behaves differently for Windows with respect to latency?
Also we might need to handle the output latency differently, i.e. set higher
than 20ms (on dmix it is currently 46ms on my device). This would then
act as a sort of jitter buffer if I understood the code correctly. PortAudio
will start output as soon as one period of audio data is available.

Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.

Regards,
Werner

···

Am 10.06.2010 09:18, schrieb Damian Minkov:

Hi Werner,

here is the source(of the hostapi alsa) for the latest binary that is
in the trunk.

Thanks
damencho

On Wed, Jun 9, 2010 at 8:22 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

can you send me the latest patched sources of the pa_alsa
host adapter for portaudio, I would like to dig into this a
little bit.

I've checked Twinkle's implementation of ALSA and it is _much_
simpler than Portaudio and does not deal with this complex
buffer arithmetic etc.

IMHO Portaudio's buffer management and the way it checks and
reads the data from ALSA is very complex, to state it in a
kind way :-). PA supports MMAP reads and non-MMAP reads which
complicates matters, also it combines blocking with non-blocking
read functions and it seems to have a sort of own thread
monitoring or something similar.

Maybe we need to use a stripped-down version to make it more
reliable.

Regards,
Werner

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Hi Werner,

I'm working on wideband support and I've already heavily modified the
PortAudio-related functionality in SIP Communicator. Anyway, the
changes that you describe - modifying the values for the suggested
latency and the way of choosing the input and the output devices -
don't sound like they'll cause merge problems for me because I've
refactored the general code, not the specific values we choose.

However, I think it's still a good idea to wait for a reply from
Damencho because I remember he carried out thorough testing on the
three operating systems in order to pick values for suggested latency
which work.

Best regards,
Lubo

···

On Fri, Jun 11, 2010 at 9:33 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Hi,

the suggested latency was really a problem to figure it out. As I
committed the first version there came some complains that there is no
sound (I think it was again linux) and I had to rework it. So I tested
current parameters and to be sure they are working and working on all
of the computers out there. I don't remember right now why the value
for windows had to be so high. What was my starting point was audacity
as they also use portaudio and it also runs on all of the operating
systems. But that's the reason for those values, it's compatibility.
Also for windows it's currently working with the windows host api
which has highest latency. As I follow latest threads in portaudio
mailinglist most of others windows host api have problems with windows
7.

Regards
damencho

···

On Fri, Jun 11, 2010 at 9:47 PM, Lubomir Marinov <lubo@sip-communicator.org> wrote:

On Fri, Jun 11, 2010 at 9:33 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.

Hi Werner,

I'm working on wideband support and I've already heavily modified the
PortAudio-related functionality in SIP Communicator. Anyway, the
changes that you describe - modifying the values for the suggested
latency and the way of choosing the input and the output devices -
don't sound like they'll cause merge problems for me because I've
refactored the general code, not the specific values we choose.

However, I think it's still a good idea to wait for a reply from
Damencho because I remember he carried out thorough testing on the
three operating systems in order to pick values for suggested latency
which work.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Hi,

with latest changes from Lubomir I made some test. At first I put
prints in PortAudio Datasource stream which prints the time between
reads and there are constant, actually they vary between 15-23 ms, but
seems really constant in this interval. Then I put the same prints but
this time for reading and writing rtp data (in
RTPConnectorOutputStream and RTPConnectorInputStream). And here is
some of it:

     [java] read 238
     [java] read 0
     [java] read 0
     [java] read 1
     [java] read 0
     [java] read 2
     [java] read 1
     [java] read 1
     [java] read 0
     [java] read 0
     [java] read 2
     [java] read 0
     [java] write 11
     [java] write 22
     [java] write 29
     [java] write 21
     [java] write 22
     [java] write 17
     [java] write 21
     [java] write 20
     [java] write 20
     [java] write 24
     [java] read 221

You can see the bursts in here. The times are times between previous
operation, respectively read or write. Maybe we can just decrease the
buffer of receive socket and everything will be ok.

WDYT?
damencho

···

On Fri, Jun 11, 2010 at 11:12 PM, Damian Minkov <damencho@sip-communicator.org> wrote:

Hi,

the suggested latency was really a problem to figure it out. As I
committed the first version there came some complains that there is no
sound (I think it was again linux) and I had to rework it. So I tested
current parameters and to be sure they are working and working on all
of the computers out there. I don't remember right now why the value
for windows had to be so high. What was my starting point was audacity
as they also use portaudio and it also runs on all of the operating
systems. But that's the reason for those values, it's compatibility.
Also for windows it's currently working with the windows host api
which has highest latency. As I follow latest threads in portaudio
mailinglist most of others windows host api have problems with windows
7.

Regards
damencho

On Fri, Jun 11, 2010 at 9:47 PM, Lubomir Marinov > <lubo@sip-communicator.org> wrote:

On Fri, Jun 11, 2010 at 9:33 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.

Hi Werner,

I'm working on wideband support and I've already heavily modified the
PortAudio-related functionality in SIP Communicator. Anyway, the
changes that you describe - modifying the values for the suggested
latency and the way of choosing the input and the output devices -
don't sound like they'll cause merge problems for me because I've
refactored the general code, not the specific values we choose.

However, I think it's still a good idea to wait for a reply from
Damencho because I remember he carried out thorough testing on the
three operating systems in order to pick values for suggested latency
which work.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#19

Hi again,

hum I tested this approach it doesn't solves the problem, again I can
see those bursts.

Regards
damencho

···

On Wed, Jun 16, 2010 at 1:46 PM, Damian Minkov <damencho@sip-communicator.org> wrote:

Hi,

with latest changes from Lubomir I made some test. At first I put
prints in PortAudio Datasource stream which prints the time between
reads and there are constant, actually they vary between 15-23 ms, but
seems really constant in this interval. Then I put the same prints but
this time for reading and writing rtp data (in
RTPConnectorOutputStream and RTPConnectorInputStream). And here is
some of it:

\[java\] read 238
\[java\] read 0
\[java\] read 0
\[java\] read 1
\[java\] read 0
\[java\] read 2
\[java\] read 1
\[java\] read 1
\[java\] read 0
\[java\] read 0
\[java\] read 2
\[java\] read 0
\[java\] write 11
\[java\] write 22
\[java\] write 29
\[java\] write 21
\[java\] write 22
\[java\] write 17
\[java\] write 21
\[java\] write 20
\[java\] write 20
\[java\] write 24
\[java\] read 221

You can see the bursts in here. The times are times between previous
operation, respectively read or write. Maybe we can just decrease the
buffer of receive socket and everything will be ok.

WDYT?
damencho

On Fri, Jun 11, 2010 at 11:12 PM, Damian Minkov > <damencho@sip-communicator.org> wrote:

Hi,

the suggested latency was really a problem to figure it out. As I
committed the first version there came some complains that there is no
sound (I think it was again linux) and I had to rework it. So I tested
current parameters and to be sure they are working and working on all
of the computers out there. I don't remember right now why the value
for windows had to be so high. What was my starting point was audacity
as they also use portaudio and it also runs on all of the operating
systems. But that's the reason for those values, it's compatibility.
Also for windows it's currently working with the windows host api
which has highest latency. As I follow latest threads in portaudio
mailinglist most of others windows host api have problems with windows
7.

Regards
damencho

On Fri, Jun 11, 2010 at 9:47 PM, Lubomir Marinov >> <lubo@sip-communicator.org> wrote:

On Fri, Jun 11, 2010 at 9:33 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.

Hi Werner,

I'm working on wideband support and I've already heavily modified the
PortAudio-related functionality in SIP Communicator. Anyway, the
changes that you describe - modifying the values for the suggested
latency and the way of choosing the input and the output devices -
don't sound like they'll cause merge problems for me because I've
refactored the general code, not the specific values we choose.

However, I think it's still a good idea to wait for a reply from
Damencho because I remember he carried out thorough testing on the
three operating systems in order to pick values for suggested latency
which work.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net