[sip-comm-dev] The 1.1 Release and Port Audio


#1

Folks,

First, I'd like to thank all those who gave us feedback on how port
audio is working (or not).

I had mentioned a couple of days ago that I'd like us to release our 1.1
version one of these days. However, given the issues that we are
experiencing with PortAudio, and how important we all agree they are, I
am willing to accept a delay of a few weeks.

We'll start tracking the PortAudio issues as soon as the holidays here
are over.

Until then, to all those who are in a location celebrating x-mas and
NYE, enjoy the holidays!

Cheers,
Emil

···

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


#2

Hi Emil,

I agree that it is better to wait before releasing v1.1.
The audio, as well as ZRTP, should be working well before this release.

To all SC fans, all the best in 2010.

Earl

Emil Ivov wrote:

···

Folks,

First, I'd like to thank all those who gave us feedback on how port
audio is working (or not).

I had mentioned a couple of days ago that I'd like us to release our 1.1
version one of these days. However, given the issues that we are
experiencing with PortAudio, and how important we all agree they are, I
am willing to accept a delay of a few weeks.

We'll start tracking the PortAudio issues as soon as the holidays here
are over.

Until then, to all those who are in a location celebrating x-mas and
NYE, enjoy the holidays!

Cheers,
Emil

---------------------------------------------------------------------
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

Dear all,

after some long debug and test session I managed to solve the portaudio
problems, at least on my system :slight_smile: . I identified and fixed several
problems, mainly in portaudio code. This is not to blame portaudion but
there might be as well problems in the Linux soundcard drivers, ALSA
libs etc.

The problema identified:
- the ALSA function snd_pcm_avail_update() seems not to work as expected
  and documented. Portaudio makes heavy use of this method. According to
  ALSA documentation I replaced this function with snd_pcm_avail() that
  seems to work better because it really asks the driver to get status
  information. The first function only gets data from the "cache".
  However, I'll test this when I get some more evidence, but for
  the time being it's ok.

- SC uses a sample rate of 44100 Hz, the "default" ALSA device in my
  system is set to 48000 Hz. This causes massive underruns when playing
  sound. Unfortunately portaudio does not recover very good from
  underruns and this lead to the very bad sound quality. I put in a few
  lines of code to enhance underrun recovery. The sound quality is better
  but not really good. To get a real good sound quality a user shall
  use a .asoundrc file to adapt the sample rate. The minimum .asoundrc
  file looks like this:

pcm.my_card {
    type hw
    card 0
    }

pcm.!default {
    type plug
    slave {
        pcm "my_card"
        rate 44100
    }
}

  This sets the sample rate of the "default" device to 44100. Even then
  underruns occur but the recovery code can handle them much better as with
  48000 Hz
  Underruns seems to occur if SC is on load (garbage collection may be?).

- A similar problem was at the capture device: portaudio did not recover
  well from overruns, in fact it caused the portaudio read function to enter
  an endless loop. After an overrun portaudio did not restart the PCM
  capture device before it tried to get data and thus entered the loop.
  Here again I put in a few lines to enhance the overrun recovery. No
  more blocks in SC noew (at least not from this problem :slight_smile: ).

I'll send the modified portaudio code (it's only the linux alsa code part)
after cleaning it up. Because SC statically links the portaudio code into
the jportaudio lib these modification do not interfere with "normal" portaudio
shared libs.

I did some more safeguards in SC code (portaudio clip implementation).

Other enhancements when parsing SDP will follow.

BTW: audio notifications fail during a call (for example the ZRTP sound
notification) if you select the hw:0.0 devices. This also depends on the
soundcard. Thus it should be mandated to use the "default" device for
playback and notification.

That's it for now. Some more news to come - stay tuned :slight_smile: .

Regards,
Werner

···

Am 27.12.2009 12:09, schrieb Earl:

Hi Emil,

I agree that it is better to wait before releasing v1.1.
The audio, as well as ZRTP, should be working well before this release.

To all SC fans, all the best in 2010.

Earl

Emil Ivov wrote:

Folks,

First, I'd like to thank all those who gave us feedback on how port
audio is working (or not).

I had mentioned a couple of days ago that I'd like us to release our 1.1
version one of these days. However, given the issues that we are
experiencing with PortAudio, and how important we all agree they are, I
am willing to accept a delay of a few weeks.

We'll start tracking the PortAudio issues as soon as the holidays here
are over.

Until then, to all those who are in a location celebrating x-mas and
NYE, enjoy the holidays!

Cheers,
Emil

---------------------------------------------------------------------
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,

Dear all,

after some long debug and test session I managed to solve the portaudio
problems, at least on my system :slight_smile: . I identified and fixed several
problems, mainly in portaudio code. This is not to blame portaudion but
there might be as well problems in the Linux soundcard drivers, ALSA
libs etc.

The problema identified:
- the ALSA function snd_pcm_avail_update() seems not to work as expected
and documented. Portaudio makes heavy use of this method. According to
ALSA documentation I replaced this function with snd_pcm_avail() that
seems to work better because it really asks the driver to get status
information. The first function only gets data from the "cache".
However, I'll test this when I get some more evidence, but for
the time being it's ok.

Don't you think its good to report this to portaudio mailing list. So
the guys that wrote alsa hostapi for portaudio can give opinion and if
its ok they can include your changes in portaudio.

- SC uses a sample rate of 44100 Hz, the "default" ALSA device in my
system is set to 48000 Hz. This causes massive underruns when playing
sound. Unfortunately portaudio does not recover very good from
underruns and this lead to the very bad sound quality. I put in a few
lines of code to enhance underrun recovery. The sound quality is better
but not really good. To get a real good sound quality a user shall
use a .asoundrc file to adapt the sample rate. The minimum .asoundrc
file looks like this:

pcm.my_card {
type hw
card 0
}

pcm.!default {
type plug
slave {
pcm "my_card"
rate 44100
}
}

This sets the sample rate of the "default" device to 44100. Even then
underruns occur but the recovery code can handle them much better as with
48000 Hz
Underruns seems to occur if SC is on load (garbage collection may be?).

As I was testing I saw that most common for sound devices is to be
opened in 44100, as javasound was doing (in the java part of course,
don't know about the native one :)) and most OS support it. That was
the reason for doing this, and this was added for the echocancel to
work and for using speexdsp resampler cause its better than the one
provided by jmf or fmj (both I think are linear).
But as you mention it I saw and that every device has its
defaultSampleRate, we can use it and open in the default sample rate
and apply resample if needed.

- A similar problem was at the capture device: portaudio did not recover
well from overruns, in fact it caused the portaudio read function to enter
an endless loop. After an overrun portaudio did not restart the PCM
capture device before it tried to get data and thus entered the loop.
Here again I put in a few lines to enhance the overrun recovery. No
more blocks in SC noew (at least not from this problem :slight_smile: ).

I'll send the modified portaudio code (it's only the linux alsa code part)
after cleaning it up. Because SC statically links the portaudio code into
the jportaudio lib these modification do not interfere with "normal" portaudio
shared libs.

I did some more safeguards in SC code (portaudio clip implementation).

I'm waiting for the changes so I can apply all the mention changes:
yours and those I'm writing for and those in the other email
concerning SIGSEGV.

Other enhancements when parsing SDP will follow.

BTW: audio notifications fail during a call (for example the ZRTP sound
notification) if you select the hw:0.0 devices. This also depends on the
soundcard. Thus it should be mandated to use the "default" device for
playback and notification.

I think that this is because the default device is routed through
pulseaudio and when using hw:0.0 you are using directly alsa and if
dmix is not activated (I thought its acivated by default on current
distributions) the pulse audio is already taken the device so we
cannot use it.

Thanks for all the observations and testing and code of course. Long
live OSS :slight_smile: I think fixing those things won't take long and soon we
will be ready for 1.1.

Thanks once again
damencho

···

2009/12/27 Werner Dittmann <Werner.Dittmann@t-online.de>:

That's it for now. Some more news to come - stay tuned :slight_smile: .

Regards,
Werner

Am 27.12.2009 12:09, schrieb Earl:

Hi Emil,

I agree that it is better to wait before releasing v1.1.
The audio, as well as ZRTP, should be working well before this release.

To all SC fans, all the best in 2010.

Earl

Emil Ivov wrote:

Folks,

First, I'd like to thank all those who gave us feedback on how port
audio is working (or not).

I had mentioned a couple of days ago that I'd like us to release our 1.1
version one of these days. However, given the issues that we are
experiencing with PortAudio, and how important we all agree they are, I
am willing to accept a delay of a few weeks.

We'll start tracking the PortAudio issues as soon as the holidays here
are over.

Until then, to all those who are in a location celebrating x-mas and
NYE, enjoy the holidays!

Cheers,
Emil

---------------------------------------------------------------------
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

Hi,

Dear all,

after some long debug and test session I managed to solve the portaudio
problems, at least on my system :slight_smile: . I identified and fixed several
problems, mainly in portaudio code. This is not to blame portaudion but
there might be as well problems in the Linux soundcard drivers, ALSA
libs etc.

The problema identified:
- the ALSA function snd_pcm_avail_update() seems not to work as expected
and documented. Portaudio makes heavy use of this method. According to
ALSA documentation I replaced this function with snd_pcm_avail() that
seems to work better because it really asks the driver to get status
information. The first function only gets data from the "cache".
However, I'll test this when I get some more evidence, but for
the time being it's ok.

Don't you think its good to report this to portaudio mailing list. So
the guys that wrote alsa hostapi for portaudio can give opinion and if
its ok they can include your changes in portaudio.

Yes, I'll need to subscribe to portaudio list. Then I report it to the list

- SC uses a sample rate of 44100 Hz, the "default" ALSA device in my
system is set to 48000 Hz. This causes massive underruns when playing
sound. Unfortunately portaudio does not recover very good from
underruns and this lead to the very bad sound quality. I put in a few
lines of code to enhance underrun recovery. The sound quality is better
but not really good. To get a real good sound quality a user shall
use a .asoundrc file to adapt the sample rate. The minimum .asoundrc
file looks like this:

pcm.my_card {
   type hw
   card 0
   }

pcm.!default {
   type plug
   slave {
       pcm "my_card"
       rate 44100
   }
}

This sets the sample rate of the "default" device to 44100. Even then
underruns occur but the recovery code can handle them much better as with
48000 Hz
Underruns seems to occur if SC is on load (garbage collection may be?).

As I was testing I saw that most common for sound devices is to be
opened in 44100, as javasound was doing (in the java part of course,
don't know about the native one :)) and most OS support it. That was
the reason for doing this, and this was added for the echocancel to
work and for using speexdsp resampler cause its better than the one
provided by jmf or fmj (both I think are linear).
But as you mention it I saw and that every device has its
defaultSampleRate, we can use it and open in the default sample rate
and apply resample if needed.

Using 44100 is ok. On my system (openSUSE 11.2) and may be on Debian systems
the "default" device is mapped to the plain "dmix" device. And plain "dmix"
supports 48000 _only_, no buffering etc. Thus "dmix" must be augumented with
a sample rate and thus must be wrapped with the "plug:" device.
After some more investigations I found a more suitable asoundrc (attached)
that works perfectly. This asoundrc defines a default device that supports
mixing of sounds, capture and resampling to 44100. On Linux systems place
this asoundrc in $HOME/.asoundrc (check if such a file already exists
and you may merge the contents).

The problem with portaudio and the "plain" dmix device is a misalignment of the
framebuffers (44100: 882 frames per 20ms, 48000: 960 frames per 20ms) and
the way how portaudio starts the playback device. This resulted in the very
bad sound quality and heavy underruns.

- A similar problem was at the capture device: portaudio did not recover
well from overruns, in fact it caused the portaudio read function to enter
an endless loop. After an overrun portaudio did not restart the PCM
capture device before it tried to get data and thus entered the loop.
Here again I put in a few lines to enhance the overrun recovery. No
more blocks in SC noew (at least not from this problem :slight_smile: ).

I'll send the modified portaudio code (it's only the linux alsa code part)
after cleaning it up. Because SC statically links the portaudio code into
the jportaudio lib these modification do not interfere with "normal" portaudio
shared libs.

I did some more safeguards in SC code (portaudio clip implementation).

Already comitted these small safeguards.

I'm waiting for the changes so I can apply all the mention changes:
yours and those I'm writing for and those in the other email
concerning SIGSEGV.

See attachment for the ALSA portaudio stuff. My additions and modifications
are marked with "wd-xxx" so you can find them easily.

Other enhancements when parsing SDP will follow.

BTW: audio notifications fail during a call (for example the ZRTP sound
notification) if you select the hw:0.0 devices. This also depends on the
soundcard. Thus it should be mandated to use the "default" device for
playback and notification.

I think that this is because the default device is routed through
pulseaudio and when using hw:0.0 you are using directly alsa and if
dmix is not activated (I thought its acivated by default on current
distributions) the pulse audio is already taken the device so we
cannot use it.

No, even if you use hw:0,0 then this also goes through portaudio. Portaudio
just passes through the device string and opens the specified device. portaudio
is "just" a warper around ALSA and other sound systems.

See above for "plain" dmix usage. Dmix is activated on most distributions
but is not augumented with a rate parameter and not wrapped by the plug:
device (see attached asoundrc how it should be)

Regards,
Werner

asoundrc (750 Bytes)

pa_linux_alsa.c (129 KB)

···

Am 31.12.2009 13:26, schrieb Damian Minkov:

2009/12/27 Werner Dittmann <Werner.Dittmann@t-online.de>:

.
Thanks for all the observations and testing and code of course. Long
live OSS :slight_smile: I think fixing those things won't take long and soon we
will be ready for 1.1.

Thanks once again
damencho

That's it for now. Some more news to come - stay tuned :slight_smile: .

Regards,
Werner


#6

Hi Werner,

I've just committed the changes to portaudio of possibly fixing two of
the problems. First the problem with clearing the connected streams
and segfaults when closing stream with echocancel enabled.
And also now the streams are opened with the default sample rate of the devices.

Can you test with these changes. Will everything work without the
modifications you put in .asoundrc in order to improve the sound
quality of your default devices?

Also we have experienced one more issue which I suspect is connected
to the one about buffers and alsa, the one you have reported on
portaudio list(Thanks for that :)), the one about xruns. The issue we
have seen is that in some occasions when hanging up the call the media
streams are locked up and so no more calls can be placed. When you
make a stack dump in such an occasion we can see that the lock is in
the portaudio Read method (I'm not sure about whether we have seen
this lock and in the Write method) as I was reading your description
of the xrun method I thought that this can be the reason, while
hanging up a xrun occurs and we don't get out of the read method. What
do you think about this? Is it possible?

Thanks
damencho

···

On Thu, Dec 31, 2009 at 5:05 PM, Damian Minkov <damencho@damencho.com> wrote:

Hi,
for the stuff about hw:0,0 I mean pulseaudio not portaudio, that default
device is routed through pulseaudio but hw:0,0 is directly through alsa :slight_smile:

Cheers
damencho

--- sent from my mobile

On 31 Dec 2009 15:28, "Werner Dittmann" <Werner.Dittmann@t-online.de> wrote:

Am 31.12.2009 13:26, schrieb Damian Minkov:

Hi, > > 2009/12/27 Werner Dittmann <Werner.Dittmann@t-online.de>: >> Dear
all, >> >> after some l...

Yes, I'll need to subscribe to portaudio list. Then I report it to the list

>> >> - SC uses a sample rate of 44100 Hz, the "default" ALSA device in my
>> >> >> system is set to ...

Using 44100 is ok. On my system (openSUSE 11.2) and may be on Debian systems
the "default" device is mapped to the plain "dmix" device. And plain "dmix"
supports 48000 _only_, no buffering etc. Thus "dmix" must be augumented with
a sample rate and thus must be wrapped with the "plug:" device.
After some more investigations I found a more suitable asoundrc (attached)
that works perfectly. This asoundrc defines a default device that supports
mixing of sounds, capture and resampling to 44100. On Linux systems place
this asoundrc in $HOME/.asoundrc (check if such a file already exists
and you may merge the contents).

The problem with portaudio and the "plain" dmix device is a misalignment of
the
framebuffers (44100: 882 frames per 20ms, 48000: 960 frames per 20ms) and
the way how portaudio starts the playback device. This resulted in the very
bad sound quality and heavy underruns.

>> >> - A similar problem was at the capture device: portaudio did not
>> >> recover >> well from ove...

Already comitted these small safeguards.

> I'm waiting for the changes so I can apply all the mention changes: >
> yours and those I'm writ...

See attachment for the ALSA portaudio stuff. My additions and modifications
are marked with "wd-xxx" so you can find them easily.

>> >> Other enhancements when parsing SDP will follow. >> >> BTW: audio
>> >> notifications fail durin...

No, even if you use hw:0,0 then this also goes through portaudio. Portaudio
just passes through the device string and opens the specified device.
portaudio
is "just" a warper around ALSA and other sound systems.

See above for "plain" dmix usage. Dmix is activated on most distributions
but is not augumented with a rate parameter and not wrapped by the plug:
device (see attached asoundrc how it should be)

Regards,
Werner

. > Thanks for all the observations and testing and code of course. Long >
live OSS :slight_smile: I think fi...

---------------------------------------------------------------------
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

Hi Damian,

I'm just trying to get you changes in jportaudio (currently it seems
the SVN repository is down?). The I test it, of course :slight_smile: .

Hi Werner,

I've just committed the changes to portaudio of possibly fixing two of
the problems. First the problem with clearing the connected streams
and segfaults when closing stream with echocancel enabled.
And also now the streams are opened with the default sample rate of the devices.

Can you test with these changes. Will everything work without the
modifications you put in .asoundrc in order to improve the sound
quality of your default devices?

Also we have experienced one more issue which I suspect is connected
to the one about buffers and alsa, the one you have reported on
portaudio list(Thanks for that :)), the one about xruns. The issue we
have seen is that in some occasions when hanging up the call the media
streams are locked up and so no more calls can be placed. When you
make a stack dump in such an occasion we can see that the lock is in
the portaudio Read method (I'm not sure about whether we have seen
this lock and in the Write method) as I was reading your description
of the xrun method I thought that this can be the reason, while
hanging up a xrun occurs and we don't get out of the read method. What
do you think about this? Is it possible?

Exactly that is the problem: if xrun (overrun in this case) occurs then
portaudio ALSA does not handle that very well. The portaudio code does
not return to the application and enters an endless loop in a poll
function. The modifications I did in portaudio code prevent this.

Regards,
Werner

···

Am 04.01.2010 10:18, schrieb Damian Minkov:

Thanks
damencho

On Thu, Dec 31, 2009 at 5:05 PM, Damian Minkov <damencho@damencho.com> wrote:

Hi,
for the stuff about hw:0,0 I mean pulseaudio not portaudio, that default
device is routed through pulseaudio but hw:0,0 is directly through alsa :slight_smile:

Cheers
damencho

--- sent from my mobile

On 31 Dec 2009 15:28, "Werner Dittmann" <Werner.Dittmann@t-online.de> wrote:

Am 31.12.2009 13:26, schrieb Damian Minkov:

Hi, > > 2009/12/27 Werner Dittmann <Werner.Dittmann@t-online.de>: >> Dear
all, >> >> after some l...

Yes, I'll need to subscribe to portaudio list. Then I report it to the list

- SC uses a sample rate of 44100 Hz, the "default" ALSA device in my

system is set to ...

Using 44100 is ok. On my system (openSUSE 11.2) and may be on Debian systems
the "default" device is mapped to the plain "dmix" device. And plain "dmix"
supports 48000 _only_, no buffering etc. Thus "dmix" must be augumented with
a sample rate and thus must be wrapped with the "plug:" device.
After some more investigations I found a more suitable asoundrc (attached)
that works perfectly. This asoundrc defines a default device that supports
mixing of sounds, capture and resampling to 44100. On Linux systems place
this asoundrc in $HOME/.asoundrc (check if such a file already exists
and you may merge the contents).

The problem with portaudio and the "plain" dmix device is a misalignment of
the
framebuffers (44100: 882 frames per 20ms, 48000: 960 frames per 20ms) and
the way how portaudio starts the playback device. This resulted in the very
bad sound quality and heavy underruns.

- A similar problem was at the capture device: portaudio did not
recover >> well from ove...

Already comitted these small safeguards.

I'm waiting for the changes so I can apply all the mention changes: >
yours and those I'm writ...

See attachment for the ALSA portaudio stuff. My additions and modifications
are marked with "wd-xxx" so you can find them easily.

Other enhancements when parsing SDP will follow. >> >> BTW: audio
notifications fail durin...

No, even if you use hw:0,0 then this also goes through portaudio. Portaudio
just passes through the device string and opens the specified device.
portaudio
is "just" a warper around ALSA and other sound systems.

See above for "plain" dmix usage. Dmix is activated on most distributions
but is not augumented with a rate parameter and not wrapped by the plug:
device (see attached asoundrc how it should be)

Regards,
Werner

. > Thanks for all the observations and testing and code of course. Long >
live OSS :slight_smile: I think fi...

---------------------------------------------------------------------
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


#8

Hi Damian,

here the rsults of my test runs with the new jportaudio code
and no .asoundrc:

These modifications do not set the sample rate to 48000Hz as expected:

        if(outputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(outputStreamParameters->device)->defaultSampleRate;
        }
        else if(inputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(inputStreamParameters->device)->defaultSampleRate;
        }

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

The other changes you made to protect against SIGSEGV work in most but not in
all cases. Assuming that playback (write) and capture (read) are working in
two different threads then your fix leaves a small window of unsynchronized
data access. See the code snippet from the read funtion:

...
        if(inStream->connectedToStream != NULL)
        {
            if(((PortAudioStream *)inStream->connectedToStream)->startCaching == 0)
                ((PortAudioStream *)inStream->connectedToStream)->startCaching = 1;
            else if(((PortAudioStream *)inStream->connectedToStream)->first != NULL)
            {
                short tempBuffer[160];
                speex_resampler_process_interleaved_int(
                        inStream->inputResampler,
                        res,
                        &in_len,
                        tempBuffer,
                        //data,
                         &frames);

                if(inStream->echoState != NULL)
                {
                    struct timeval tv;
                    gettimeofday(&tv,NULL);

                    int time = tv.tv_sec*1000 + tv.tv_usec/1000;
                    Buffer *b = getBuffer(
                        (PortAudioStream *)inStream->connectedToStream, time);
                    if(b != NULL)
                    {
                        short *t;
                        t = b->data;
                        speex_echo_cancellation(
                                inStream->echoState, tempBuffer, t, data);
                        free(b);
                    }
                }

                if(inStream->preprocessor != NULL)
                    speex_preprocess_run(inStream->preprocessor, data);
            }
            else
...

The code checks for not NULL at the start of the if but accesses the
connctedToStream field some time later again without checking. If SC closes
the output while "read" just processes speex_resampler....() for example
then getBuffer() may fail with SIGSEGV. Agreed, the time window is very small
but on real dual or multi-core processors where threads can really work in parallel
this might happen more often than on single core processors. IMHO you
need to synchronize the close functions in SC somehow.

Regards,
Werner

···

Am 04.01.2010 10:18, schrieb Damian Minkov:

Hi Werner,

I've just committed the changes to portaudio of possibly fixing two of
the problems. First the problem with clearing the connected streams
and segfaults when closing stream with echocancel enabled.
And also now the streams are opened with the default sample rate of the devices.

Can you test with these changes. Will everything work without the
modifications you put in .asoundrc in order to improve the sound
quality of your default devices?

Also we have experienced one more issue which I suspect is connected
to the one about buffers and alsa, the one you have reported on
portaudio list(Thanks for that :)), the one about xruns. The issue we
have seen is that in some occasions when hanging up the call the media
streams are locked up and so no more calls can be placed. When you
make a stack dump in such an occasion we can see that the lock is in
the portaudio Read method (I'm not sure about whether we have seen
this lock and in the Write method) as I was reading your description
of the xrun method I thought that this can be the reason, while
hanging up a xrun occurs and we don't get out of the read method. What
do you think about this? Is it possible?

Thanks
damencho

<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


#9

Just an additional info.

Hi Damian,

here the rsults of my test runs with the new jportaudio code
and no .asoundrc:

These modifications do not set the sample rate to 48000Hz as expected:

        if(outputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(outputStreamParameters->device)->defaultSampleRate;
        }
        else if(inputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(inputStreamParameters->device)->defaultSampleRate;
        }

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

However, the ,odifications I did in the portaudio ALSA source elminate most
of the bad effects. The sound quality is ok, the capture quality also. Some
small glitches but nothing really bad. Of course using the proposed .asoundrc
enhances it even more. Maybe we can give some advise to Linux SC users to
check the .asoundrc if they would like to get better sound quality. What
do you think?

Werner

···

Am 04.01.2010 15:00, schrieb Werner Dittmann:

---------------------------------------------------------------------
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,

Hi Damian,

These modifications do not set the sample rate to 48000Hz as expected:

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

This is really strange, it seems then that the device reports that the
defult sample rate is not 48kHz.

Agreed, the time window is very small

but on real dual or multi-core processors where threads can really work in parallel
this might happen more often than on single core processors. IMHO you
need to synchronize the close functions in SC somehow.

Yes you are right I will look in SC to synch closes. Thanks

damencho

···

On Mon, Jan 4, 2010 at 4:00 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Regards,
Werner

Am 04.01.2010 10:18, schrieb Damian Minkov:

Hi Werner,

I've just committed the changes to portaudio of possibly fixing two of
the problems. First the problem with clearing the connected streams
and segfaults when closing stream with echocancel enabled.
And also now the streams are opened with the default sample rate of the devices.

Can you test with these changes. Will everything work without the
modifications you put in .asoundrc in order to improve the sound
quality of your default devices?

Also we have experienced one more issue which I suspect is connected
to the one about buffers and alsa, the one you have reported on
portaudio list(Thanks for that :)), the one about xruns. The issue we
have seen is that in some occasions when hanging up the call the media
streams are locked up and so no more calls can be placed. When you
make a stack dump in such an occasion we can see that the lock is in
the portaudio Read method (I'm not sure about whether we have seen
this lock and in the Write method) as I was reading your description
of the xrun method I thought that this can be the reason, while
hanging up a xrun occurs and we don't get out of the read method. What
do you think about this? Is it possible?

Thanks
damencho

<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

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


#11

Hi,

Hi Damian,

These modifications do not set the sample rate to 48000Hz as expected:

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

This is really strange, it seems then that the device reports that the
defult sample rate is not 48kHz.

Yes, indeed. Maybe yet another obstacle of portaudio in conjunction with
ALSA and the default device. I'll have a look how this works in portaudio's
ALSA implementation.

Werner

···

Am 04.01.2010 15:19, schrieb Damian Minkov:

On Mon, Jan 4, 2010 at 4:00 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Agreed, the time window is very small

but on real dual or multi-core processors where threads can really work in parallel
this might happen more often than on single core processors. IMHO you
need to synchronize the close functions in SC somehow.

Yes you are right I will look in SC to synch closes. Thanks

damencho

Regards,
Werner

Am 04.01.2010 10:18, schrieb Damian Minkov:

Hi Werner,

I've just committed the changes to portaudio of possibly fixing two of
the problems. First the problem with clearing the connected streams
and segfaults when closing stream with echocancel enabled.
And also now the streams are opened with the default sample rate of the devices.

Can you test with these changes. Will everything work without the
modifications you put in .asoundrc in order to improve the sound
quality of your default devices?

Also we have experienced one more issue which I suspect is connected
to the one about buffers and alsa, the one you have reported on
portaudio list(Thanks for that :)), the one about xruns. The issue we
have seen is that in some occasions when hanging up the call the media
streams are locked up and so no more calls can be placed. When you
make a stack dump in such an occasion we can see that the lock is in
the portaudio Read method (I'm not sure about whether we have seen
this lock and in the Write method) as I was reading your description
of the xrun method I thought that this can be the reason, while
hanging up a xrun occurs and we don't get out of the read method. What
do you think about this? Is it possible?

Thanks
damencho

<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

---------------------------------------------------------------------
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


#12

Hi,

I don't think this is a good idea about .asoundrc, cause we will make
things too complicated. And as I understand .asoundrc forces
resampling, but we do this in our native part we must figure it out
and fix it in our part so we can compatible with all hardware.
I've just committed two more changes. I think I managed to synchronize
reads and closes so the thing with segfault and echocancel must no
longer appear. (I hope so:)).
And also I applied your changes about xrun problems in portaudio which
we statically link.
About the changes with replacing snd_pcm_avail_update with
snd_pcm_avail, I couldn't applied them cause the binaries we build are
build on debian etch for compatibility and there the version of
libasound2 is 1.0.13-2 and snd_pcm_avail is missing.

Thanks
damencho

···

On Mon, Jan 4, 2010 at 4:06 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Just an additional info.

Am 04.01.2010 15:00, schrieb Werner Dittmann:

Hi Damian,

here the rsults of my test runs with the new jportaudio code
and no .asoundrc:

These modifications do not set the sample rate to 48000Hz as expected:

    if\(outputStreamParameters\)
    \{
        defSampleRate =
            Pa\_GetDeviceInfo\(outputStreamParameters\-&gt;device\)\-&gt;defaultSampleRate;
    \}
    else if\(inputStreamParameters\)
    \{
        defSampleRate =
            Pa\_GetDeviceInfo\(inputStreamParameters\-&gt;device\)\-&gt;defaultSampleRate;
    \}

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

However, the ,odifications I did in the portaudio ALSA source elminate most
of the bad effects. The sound quality is ok, the capture quality also. Some
small glitches but nothing really bad. Of course using the proposed .asoundrc
enhances it even more. Maybe we can give some advise to Linux SC users to
check the .asoundrc if they would like to get better sound quality. What
do you think?

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


#13

I'll have a look to use some other mechanism to synchronize with
hardware. There is a functions in ALSA that explictily performs
this and exists also in previous versions of the libasound.

Also I found some inidiaction regarding the samplerate: the
default ALSA device report a default sample rate of 44100Hz
but during the open processing ALSA sees that default is
really the dmix device and returns the fixed framesPerBuffer
size of 940 (20ms of samples for 48000). I'll check how
we can report this back to jportaudio.

Regards,
Werner

···

Am 04.01.2010 17:48, schrieb Damian Minkov:

Hi,

I don't think this is a good idea about .asoundrc, cause we will make
things too complicated. And as I understand .asoundrc forces
resampling, but we do this in our native part we must figure it out
and fix it in our part so we can compatible with all hardware.
I've just committed two more changes. I think I managed to synchronize
reads and closes so the thing with segfault and echocancel must no
longer appear. (I hope so:)).
And also I applied your changes about xrun problems in portaudio which
we statically link.
About the changes with replacing snd_pcm_avail_update with
snd_pcm_avail, I couldn't applied them cause the binaries we build are
build on debian etch for compatibility and there the version of
libasound2 is 1.0.13-2 and snd_pcm_avail is missing.

Thanks
damencho

On Mon, Jan 4, 2010 at 4:06 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Just an additional info.

Am 04.01.2010 15:00, schrieb Werner Dittmann:

Hi Damian,

here the rsults of my test runs with the new jportaudio code
and no .asoundrc:

These modifications do not set the sample rate to 48000Hz as expected:

        if(outputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(outputStreamParameters->device)->defaultSampleRate;
        }
        else if(inputStreamParameters)
        {
            defSampleRate =
                Pa_GetDeviceInfo(inputStreamParameters->device)->defaultSampleRate;
        }

Instead it leaves the sample rate at 44100Hz. I have not yet figured out
why this happens.

However, the ,odifications I did in the portaudio ALSA source elminate most
of the bad effects. The sound quality is ok, the capture quality also. Some
small glitches but nothing really bad. Of course using the proposed .asoundrc
enhances it even more. Maybe we can give some advise to Linux SC users to
check the .asoundrc if they would like to get better sound quality. What
do you think?

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


#14

Hi,

after some testing and experimenting with portaudio's ALSA code
I got the following reults (on my system):

- the "default" device is set to a playback sample rate of 44100Hz
  and has the "dmix" device as its slave. "dmix" has a fixed sample
  rate of 48000Hz
- the "default" reports the correct sample rate, an performs rate
  conversion from 44100Hz to 48000Hz to meet "dmix" requirements
- during pcmOpen in portaudio at one point the "framesPerBuffer"
  is set to 940 due to a snd_pcm_hw_parameter check.

This is not critical per se but only in conjunction
- with the number of frames that SC uses: 882 frames (20ms for 44100Hz)
- and the way portaudio's ALSA code starts the playback device
causes real bad sound quality. Mainly because of the mismatch of
the frames per buffer. I modified the code to start the playback
device much realier, in fact as soon as it is in prepared state
and some data was copied to the device.

This does not completely eliminates the sound distortions, but they are
much shorter now (1-3 seconds) and are much softer. During the short
distortion periods the sound quality is similar to a mobile phone
if you have a medium radio quality. However, the sound distortions do
not occure very often.

Due to the better handling of xrun (both playback and capture) I could
enable the old method of snd_pcm_avail_update(). Thus it should compile
and run on debian etch now.

I attach the modified code for portaudio ALSA.

Regards,
Werner

pa_linux_alsa.c (129 KB)

···

Am 04.01.2010 19:04, schrieb Werner Dittmann:

I'll have a look to use some other mechanism to synchronize with
hardware. There is a functions in ALSA that explictily performs
this and exists also in previous versions of the libasound.

Also I found some inidiaction regarding the samplerate: the
default ALSA device report a default sample rate of 44100Hz
but during the open processing ALSA sees that default is
really the dmix device and returns the fixed framesPerBuffer
size of 940 (20ms of samples for 48000). I'll check how
we can report this back to jportaudio.

Regards,
Werner

Am 04.01.2010 17:48, schrieb Damian Minkov:

Hi,

I don't think this is a good idea about .asoundrc, cause we will make
things too complicated. And as I understand .asoundrc forces
resampling, but we do this in our native part we must figure it out
and fix it in our part so we can compatible with all hardware.
I've just committed two more changes. I think I managed to synchronize
reads and closes so the thing with segfault and echocancel must no
longer appear. (I hope so:)).
And also I applied your changes about xrun problems in portaudio which
we statically link.
About the changes with replacing snd_pcm_avail_update with
snd_pcm_avail, I couldn't applied them cause the binaries we build are
build on debian etch for compatibility and there the version of
libasound2 is 1.0.13-2 and snd_pcm_avail is missing.

Thanks
damencho

<SNIP --- SNAP>


#15

Hi,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.
As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok. And as we use 44.1 and dmix is 48 at one point it comes that the
buffers are not 882 framse as we use it for 44.1, but 940 frames which
makes the bath sound quality. But I'm little confused how opening of
the the device earlier fixes the problem? And if the computing of
framesPerBuffer is wrong and the wrong value comes from
snd_pcm_hw_parameter check it seems like alsa bug ?

Cheers
damencho

···

On Tue, Jan 5, 2010 at 1:36 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi,

after some testing and experimenting with portaudio's ALSA code
I got the following reults (on my system):

- the "default" device is set to a playback sample rate of 44100Hz
and has the "dmix" device as its slave. "dmix" has a fixed sample
rate of 48000Hz
- the "default" reports the correct sample rate, an performs rate
conversion from 44100Hz to 48000Hz to meet "dmix" requirements
- during pcmOpen in portaudio at one point the "framesPerBuffer"
is set to 940 due to a snd_pcm_hw_parameter check.

This is not critical per se but only in conjunction
- with the number of frames that SC uses: 882 frames (20ms for 44100Hz)
- and the way portaudio's ALSA code starts the playback device
causes real bad sound quality. Mainly because of the mismatch of
the frames per buffer. I modified the code to start the playback
device much realier, in fact as soon as it is in prepared state
and some data was copied to the device.

This does not completely eliminates the sound distortions, but they are
much shorter now (1-3 seconds) and are much softer. During the short
distortion periods the sound quality is similar to a mobile phone
if you have a medium radio quality. However, the sound distortions do
not occure very often.

Due to the better handling of xrun (both playback and capture) I could
enable the old method of snd_pcm_avail_update(). Thus it should compile
and run on debian etch now.

I attach the modified code for portaudio ALSA.

Regards,
Werner

Am 04.01.2010 19:04, schrieb Werner Dittmann:

I'll have a look to use some other mechanism to synchronize with
hardware. There is a functions in ALSA that explictily performs
this and exists also in previous versions of the libasound.

Also I found some inidiaction regarding the samplerate: the
default ALSA device report a default sample rate of 44100Hz
but during the open processing ALSA sees that default is
really the dmix device and returns the fixed framesPerBuffer
size of 940 (20ms of samples for 48000). I'll check how
we can report this back to jportaudio.

Regards,
Werner

Am 04.01.2010 17:48, schrieb Damian Minkov:

Hi,

I don't think this is a good idea about .asoundrc, cause we will make
things too complicated. And as I understand .asoundrc forces
resampling, but we do this in our native part we must figure it out
and fix it in our part so we can compatible with all hardware.
I've just committed two more changes. I think I managed to synchronize
reads and closes so the thing with segfault and echocancel must no
longer appear. (I hope so:)).
And also I applied your changes about xrun problems in portaudio which
we statically link.
About the changes with replacing snd_pcm_avail_update with
snd_pcm_avail, I couldn't applied them cause the binaries we build are
build on debian etch for compatibility and there the version of
libasound2 is 1.0.13-2 and snd_pcm_avail is missing.

Thanks
damencho

<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

---------------------------------------------------------------------
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,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.

What is going wrong with the .asoundrc that I attached to a previous
post? Can you give some indication?

As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok.

Actually it is the "plug" device that resamples it and hands it over
to "dmix" - well, it took me some time to understand the flow inside
ALSA -:slight_smile:

And as we use 44.1 and dmix is 48 at one point it comes that the

buffers are not 882 framse as we use it for 44.1, but 940 frames which

Even 940 is somehow odd. but this is the number that ALSA reports back to
portaudio if I use the "default" device without any modifications or
a .asoundrc.

makes the bath sound quality. But I'm little confused how opening of
the the device earlier fixes the problem? And if the computing of

The modifications I made do not "open the device earlier" but one of
the modifications (int the write frunction) call the pcm_snd_start()
as soon as the playback device has some data. The original code delayed
this start call. After all, this late start causes an underrun of
data after a while, also depending on the timine of SC.

framesPerBuffer is wrong and the wrong value comes from
snd_pcm_hw_parameter check it seems like alsa bug ?

I really don't know if this is a bug nor not and how ALSA computes
this number

Regards,
Werner

···

Am 05.01.2010 14:26, schrieb Damian Minkov:

Cheers
damencho

On Tue, Jan 5, 2010 at 1:36 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi,

after some testing and experimenting with portaudio's ALSA code
I got the following reults (on my system):

- the "default" device is set to a playback sample rate of 44100Hz
and has the "dmix" device as its slave. "dmix" has a fixed sample
rate of 48000Hz
- the "default" reports the correct sample rate, an performs rate
conversion from 44100Hz to 48000Hz to meet "dmix" requirements
- during pcmOpen in portaudio at one point the "framesPerBuffer"
is set to 940 due to a snd_pcm_hw_parameter check.

This is not critical per se but only in conjunction
- with the number of frames that SC uses: 882 frames (20ms for 44100Hz)
- and the way portaudio's ALSA code starts the playback device
causes real bad sound quality. Mainly because of the mismatch of
the frames per buffer. I modified the code to start the playback
device much realier, in fact as soon as it is in prepared state
and some data was copied to the device.

This does not completely eliminates the sound distortions, but they are
much shorter now (1-3 seconds) and are much softer. During the short
distortion periods the sound quality is similar to a mobile phone
if you have a medium radio quality. However, the sound distortions do
not occure very often.

Due to the better handling of xrun (both playback and capture) I could
enable the old method of snd_pcm_avail_update(). Thus it should compile
and run on debian etch now.

I attach the modified code for portaudio ALSA.

Regards,
Werner

Am 04.01.2010 19:04, schrieb Werner Dittmann:

I'll have a look to use some other mechanism to synchronize with
hardware. There is a functions in ALSA that explictily performs
this and exists also in previous versions of the libasound.

Also I found some inidiaction regarding the samplerate: the
default ALSA device report a default sample rate of 44100Hz
but during the open processing ALSA sees that default is
really the dmix device and returns the fixed framesPerBuffer
size of 940 (20ms of samples for 48000). I'll check how
we can report this back to jportaudio.

Regards,
Werner

Am 04.01.2010 17:48, schrieb Damian Minkov:

Hi,

I don't think this is a good idea about .asoundrc, cause we will make
things too complicated. And as I understand .asoundrc forces
resampling, but we do this in our native part we must figure it out
and fix it in our part so we can compatible with all hardware.
I've just committed two more changes. I think I managed to synchronize
reads and closes so the thing with segfault and echocancel must no
longer appear. (I hope so:)).
And also I applied your changes about xrun problems in portaudio which
we statically link.
About the changes with replacing snd_pcm_avail_update with
snd_pcm_avail, I couldn't applied them cause the binaries we build are
build on debian etch for compatibility and there the version of
libasound2 is 1.0.13-2 and snd_pcm_avail is missing.

Thanks
damencho

<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

---------------------------------------------------------------------
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


#17

Hi,

Hi,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.

What is going wrong with the .asoundrc that I attached to a previous
post? Can you give some indication?

When I use it I got no sound at all, no playback and no capture. I
suppose here maybe pulseaudio is involved. You are using OpenSuse,
doesn't it has by default pulseaudio configured for the X session or
you have removed it?

As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok.

Actually it is the "plug" device that resamples it and hands it over
to "dmix" - well, it took me some time to understand the flow inside
ALSA -:slight_smile:

From http://alsa.opensrc.org/DmixPlugin I read :

"Dmix by default uses 48kHz sample rate. So, if your source is
44.1kHz, it will be upsampled to 48khz."
So whether behind the device we use from alsa is the plugin dmix or
plugin routing audio to pulseaudio everything must work as its now.

I really don't know if this is a bug nor not and how ALSA computes
this number

Yes the value is strange, cause the frame size we use is 2 for 44.1
kHz so 441*2 = 882. If we compute things like that 940/2=470 - it
seems that alsa thinks the device is working on 47 kHz, not 48 kHz or
somthing like that.

I also had a look at your device(CMI8738) description here is what I found :
"The major limitation of the CMI8738 does not support hardware
sharing, but you can just setup software sharing."
"In practice this card should be considered to be 48kHz only, even if
nominally can resample to 44.1kHz itself.".

damencho

···

On Tue, Jan 5, 2010 at 4:24 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Am 05.01.2010 14:26, schrieb Damian Minkov:

---------------------------------------------------------------------
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,

Hi,

Hi,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.

What is going wrong with the .asoundrc that I attached to a previous
post? Can you give some indication?

When I use it I got no sound at all, no playback and no capture. I
suppose here maybe pulseaudio is involved. You are using OpenSuse,
doesn't it has by default pulseaudio configured for the X session or
you have removed it?

I don't have pulseaudio active, I removed it (I don't use
Gnome). When I select "dmix" in SC's portaudio media configuration
that works fine on my system. Even the jportaudio gets back the right
sample rate (48000Hz).

As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok.

Actually it is the "plug" device that resamples it and hands it over
to "dmix" - well, it took me some time to understand the flow inside
ALSA -:slight_smile:

From http://alsa.opensrc.org/DmixPlugin I read :

"Dmix by default uses 48kHz sample rate. So, if your source is
44.1kHz, it will be upsampled to 48khz."
So whether behind the device we use from alsa is the plugin dmix or
plugin routing audio to pulseaudio everything must work as its now.

I really don't know if this is a bug nor not and how ALSA computes
this number

Yes the value is strange, cause the frame size we use is 2 for 44.1
kHz so 441*2 = 882. If we compute things like that 940/2=470 - it
seems that alsa thinks the device is working on 47 kHz, not 48 kHz or
somthing like that.

I also had a look at your device(CMI8738) description here is what I found :
"The major limitation of the CMI8738 does not support hardware
sharing, but you can just setup software sharing."
"In practice this card should be considered to be 48kHz only, even if
nominally can resample to 44.1kHz itself.".

Yes, that's way I have to use "dmix" somewhere in ALSA's device path.
Otherwise I can't play notifications during a call.

However, I hope that the latest modifications in portaudio's ALSA code
solves the problems. :slight_smile:

Regards,
Werner

···

Am 05.01.2010 16:18, schrieb Damian Minkov:

On Tue, Jan 5, 2010 at 4:24 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Am 05.01.2010 14:26, schrieb Damian Minkov:

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


#19

Hi,

I've compiled those changes into jportaudio on debian etch and
committed them, you can test the binaries. And lets see does they work
for everybody :slight_smile: as the changes doesn't affect the quality on my
system. I hope the guys from portaudio will check and confirm and
commit your changes. If you want you can report the latest
observations and send them the latest patch we integrated.

Thanks
damencho

···

On Tue, Jan 5, 2010 at 5:48 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi,

Am 05.01.2010 16:18, schrieb Damian Minkov:

Hi,

On Tue, Jan 5, 2010 at 4:24 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Am 05.01.2010 14:26, schrieb Damian Minkov:

Hi,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.

What is going wrong with the .asoundrc that I attached to a previous
post? Can you give some indication?

When I use it I got no sound at all, no playback and no capture. I
suppose here maybe pulseaudio is involved. You are using OpenSuse,
doesn't it has by default pulseaudio configured for the X session or
you have removed it?

I don't have pulseaudio active, I removed it (I don't use
Gnome). When I select "dmix" in SC's portaudio media configuration
that works fine on my system. Even the jportaudio gets back the right
sample rate (48000Hz).

As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok.

Actually it is the "plug" device that resamples it and hands it over
to "dmix" - well, it took me some time to understand the flow inside
ALSA -:slight_smile:

From http://alsa.opensrc.org/DmixPlugin I read :

"Dmix by default uses 48kHz sample rate. So, if your source is
44.1kHz, it will be upsampled to 48khz."
So whether behind the device we use from alsa is the plugin dmix or
plugin routing audio to pulseaudio everything must work as its now.

I really don't know if this is a bug nor not and how ALSA computes
this number

Yes the value is strange, cause the frame size we use is 2 for 44.1
kHz so 441*2 = 882. If we compute things like that 940/2=470 - it
seems that alsa thinks the device is working on 47 kHz, not 48 kHz or
somthing like that.

I also had a look at your device(CMI8738) description here is what I found :
"The major limitation of the CMI8738 does not support hardware
sharing, but you can just setup software sharing."
"In practice this card should be considered to be 48kHz only, even if
nominally can resample to 44.1kHz itself.".

Yes, that's way I have to use "dmix" somewhere in ALSA's device path.
Otherwise I can't play notifications during a call.

However, I hope that the latest modifications in portaudio's ALSA code
solves the problems. :slight_smile:

Regards,
Werner

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


#20

Hi Damian,

actually the binary does not work well. As I can see you have
changed a snd_pcm_avail() function call at one place where I
forgot to change it to snd_pcm_avail_update(). Is that correct?

Well, as it truned out - exactly this place is the one that
causes the most trouble (you may know Murphy's laws :slight_smile: ). After
some testing and debugging I placed an additonal check around
this to cope with wrong values and modified the write function
a little bit.

The sound quality for the "default" device is ok, sometimes a
jitter, but it works. On my system, using ALSA (no pulseaudio etc)
I can select the "dmix" device directly in SC's media configurator.
This gives much better results than "default" - the buffering
scheme for "dmix" is different and "dmix" really reports a
sample rate of 48000Hz. Thus my advise would be to select "dmix"
instead of "default" for output and notification. In any case
the modified source for portaudio should be used. Without the
modifications I made the sound quality for both device is very
bad.

If this new code works for you I can test it on my system again
(the real binary). After that I'll compile some information for
the portaudio mailing list to get some feedback.

Regards,
Werner

pa_linux_alsa.c (129 KB)

···

Am 05.01.2010 17:27, schrieb Damian Minkov:

Hi,

I've compiled those changes into jportaudio on debian etch and
committed them, you can test the binaries. And lets see does they work
for everybody :slight_smile: as the changes doesn't affect the quality on my
system. I hope the guys from portaudio will check and confirm and
commit your changes. If you want you can report the latest
observations and send them the latest patch we integrated.

Thanks
damencho

On Tue, Jan 5, 2010 at 5:48 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi,

Am 05.01.2010 16:18, schrieb Damian Minkov:

Hi,

On Tue, Jan 5, 2010 at 4:24 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Am 05.01.2010 14:26, schrieb Damian Minkov:

Hi,

I tried your modifications - working for me (on Ubuntu 9.10 with
pulseaudio). I also tried applying your asoundrc so I can test with
dmix but with no luck.

What is going wrong with the .asoundrc that I attached to a previous
post? Can you give some indication?

When I use it I got no sound at all, no playback and no capture. I
suppose here maybe pulseaudio is involved. You are using OpenSuse,
doesn't it has by default pulseaudio configured for the X session or
you have removed it?

I don't have pulseaudio active, I removed it (I don't use
Gnome). When I select "dmix" in SC's portaudio media configuration
that works fine on my system. Even the jportaudio gets back the right
sample rate (48000Hz).

As I understand from your descriptions the actual problem is wrong
computing of framesPerBuffer. Dmix uses 48 kHz and if the supplied
media is 44.1 (in our case) it will resample it and everything will be
ok.

Actually it is the "plug" device that resamples it and hands it over
to "dmix" - well, it took me some time to understand the flow inside
ALSA -:slight_smile:

>From http://alsa.opensrc.org/DmixPlugin I read :
"Dmix by default uses 48kHz sample rate. So, if your source is
44.1kHz, it will be upsampled to 48khz."
So whether behind the device we use from alsa is the plugin dmix or
plugin routing audio to pulseaudio everything must work as its now.

I really don't know if this is a bug nor not and how ALSA computes
this number

Yes the value is strange, cause the frame size we use is 2 for 44.1
kHz so 441*2 = 882. If we compute things like that 940/2=470 - it
seems that alsa thinks the device is working on 47 kHz, not 48 kHz or
somthing like that.

I also had a look at your device(CMI8738) description here is what I found :
"The major limitation of the CMI8738 does not support hardware
sharing, but you can just setup software sharing."
"In practice this card should be considered to be 48kHz only, even if
nominally can resample to 44.1kHz itself.".

Yes, that's way I have to use "dmix" somewhere in ALSA's device path.
Otherwise I can't play notifications during a call.

However, I hope that the latest modifications in portaudio's ALSA code
solves the problems. :slight_smile:

Regards,
Werner

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