Mihai Moldovan | 19 Apr 09:07 2015
Picon

[PATCH] module-coreaudio-device: do not corrupt the heap/stack for devices with more channels than supported.

Instead, clamp the channel number to PA_CHANNELS_MAX. That's better than
overwriting random data, crashing and burning, and arguably better than
skipping the device completely.

Signed-off-by: Mihai Moldovan <ionic <at> ionic.de>
---
 src/modules/macosx/module-coreaudio-device.c | 34
++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 10 deletions(-)

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Glenn Golden | 18 Apr 15:10 2015

Re: ThinkPad T-510 audio output mute LED non-workingness

[NOTE: This is an edited/expanded version of a previous post which never made
it to the list because it had an attachment that was too big.]

David Henningsson <david.henningsson <at> canonical.com> [2015-04-14 13:32:42 +0200]:
> 
> Just to check - you did press F4 or F5 to make all capture controls show up,
> right?
> 

Yes. I also widened out the display to make sure there were no more controls
hidden on either side.

In case it may be of interest to anyone with the same or similar issue,
here is a "behavioral schematic" that seems to accurately reflect the
relationship between {pavucontrol/pactl/pacmd/amixer} mute and the hardware
mute function and LEDs on my T-510, showing the differences across the
kernel change between 3.18 and 3.19:

    http://misc.postpro.net/t510led/schematic_view.jpg

(The diagram isn't intended to reflect actual circuit topology, of which
I have no knowledge; only that it seems to schematically capture the observed
muting (and mute LED) behavior.)

The main thing to note is that in 3.18, when the driver fielded the mute
key events itself, it handled those events by toggling the state of a
low-level hardware-based mute switch (upper right dotted box). This HW mute
evidently applied only to the speaker, not headphones, and seems to have no
relationship to the pavucontrol/pactl/amixer mixer-based mute.  Also -- and
central to the issue here -- invoking the HW mute function via the mute key
(Continue reading)

Mihai Moldovan | 18 Apr 07:07 2015
Picon

[PATCH] module-coreaudio-device: get channel name as CFString and convert to plain C string.


The old code fetched the channel name via AudioObjectGetPropertyData()
and accessed the "returned" data as a plain char buffer.

This may or may not have worked at some point according to the Apple
CFString documentation, which warns that the actual data layout is an
implementation detail and subject to change at any time.

On recent OS X versions, this behavior led to "random data" channel
names like >H��{, H��{<.

We need to actually let AudioObjectGetPropertyData() populate a CFString
struct and convert this into a plain char buffer.

Signed-off-by: Mihai Moldovan <ionic <at> ionic.de>
---
 src/modules/macosx/module-coreaudio-device.c | 37
++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Tanu Kaskinen | 17 Apr 22:26 2015
Picon

[PATCH v2 0/5] Add default volume to ports

This is pretty much a complete rewrite of the patches that intended to
fix bad volume behaviour on Terratec Aureon Dual USB. These patches
add a new default volume attribute to ports and alsa-mixer paths, and
use that to fix the Aureon volume bug[1].

The default volume of all analog paths, not just Aureon, is now 30%
instead of 100%. Also, the port default volume is now considered when
switching ports. That means, for example, that on the first boot of
a laptop with speakers and a headphone jack (unplugged), the speakers
get their default volume set as before (based on the hardware volume),
but when plugging in headphones, the sink volume jumps to 30%. That's
a good thing, because the speaker volume won't affect the default
headphone volume like it has affected so far.

Here's a link to the v1 patch set discussion, where the device default
volumes were discussed in some length:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/22253

[1] https://bugs.freedesktop.org/show_bug.cgi?id=81777

Tanu Kaskinen (5):
  core: Add default volume to ports
  When switching ports, use the port default volume
  conf-parser: Add pa_config_parse_volume()
  alsa-mixer: Add "default-volume" path option
  alsa-mixer: Improve volume handling for Terratec Aureon Dual USB

 src/Makefile.am                                    |  6 +-
 src/modules/alsa/alsa-mixer.c                      |  6 ++
 src/modules/alsa/alsa-mixer.h                      |  1 +
(Continue reading)

Borries Demeler | 17 Apr 17:00 2015
Picon

stumped on Slackware 14.1

I am unable to get pulseaudio to work on my Slackware 14.1 system.
It used to work and then for some unknown reason it started to fail.
I needed pulseaudio to get Skype to work, which requires it. I also
had to build a 32-bit binary distro to support Skype, but now I am
at a loss on how to re-activate it and I am clueless as to what broke
the working install. At the core, the problem seems to be related to
pulseaudio's failure to load some alsa modules. Any help would be 
greatly appreciated! /etc/pulse contents are attached.
I already tried to remove my ~/.config/pulse directory and recreate it,
to no avail.

Thanks!!!

-b.

Here are some diagnostics:

lspci | grep -i audio:
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio
Controller (rev 04)

cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xc1610000 irq 46

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: CX20590 Analog [CX20590 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
(Continue reading)

Sergey Shpikin | 17 Apr 08:17 2015

Skips and latency issues on VIA VT1708S

On my not-so-mighty system (Intel G620) I have underruns from time to time. As a direct result of that the latency increases. If some program has chosen a small latency and had underruns because of CPU load the Pulseaudio server may increase the latency to 100+ ms which is applied to every program and worst of all, it's never decreased. The only way is to restart PA and all its clients. Our bug discussion ( https://bugs.freedesktop.org/show_bug.cgi?id=49608 ) has come to nowhere as it seems that no PA developers are interested in this. So I decided to post here.

My question is, why dmix works flawlessly on this system while PA skips? I have this ALSA setup when using dmix:

> aplay -v /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S32_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Soft volume PCM
Control: PCM Playback Volume
min_dB: -51
max_dB: 0
resolution: 256
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : ENABLE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 4611686018427387904
  silence_threshold: 0
  silence_size : 4611686018427387904
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0

16 periods, 21.3 ms each, it results in 341 ms. Yet there's no audible latency which makes me think that dmix's latency is approximately equals the period size, i.e. 21 ms. If I setup Pulseaudio so it uses the same configuration (tsched=0, fragment size=21, fragments=16) the latency equals the whole buffer size, 336 ms as reported by pacmd list-sinks and noticeable well in LMMS. It is unacceptable of course.  So is there a way to make PA work just like dmix, with the fixed latency of 21 ms or alike and without skips at the same time? With PA's interrupt-driven model I can get either bad latency with presumably no skips or good latency and underruns from time to time. With the new timer-based scheduling I have both skips and growing latency up to 168 ms or something like this in the end of the working day.

Another question is about pavucontrol. I usually listen to music in Chrome streaming from grooveshark, it uses HTML5 Audio. When I launch pavucontrol the first time, the playback skips pretty badly and the latency increases. The same sometimes happens when I launch pacmd list-sinks. No way these tools occupy so much CPU that Chrome can't sink audio to the server. It's like they block somewhere in the server and it can't accept audio from the outside. This doesn't happen when launching any other app except LMMS which also makes Chrome skip (if tsched=0) or produce garbled sound for a while (if tsched is not defined, i.e. =1) after which PA recovers.

Many internal details are provided in the bug I mentioned before so you can check I've tried pretty many things to make it work, including EFI update and various snd-hda-intel module options. I also have to note that all of this is not the issue on my home PC which is quite faster, i7-2600 with PCI SB Live 7.1. I use preemptive kernels on both machines, compiled from the patched pf source (pf-kernel). With the stock Debian kernel the matters are even worse and I had underruns on the home PC as well.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Arun Raghavan | 16 Apr 15:22 2015
Picon

Re: [PATCH] Add a .travis.yml for Travis CI

On 16 April 2015 at 18:47, Felipe Sateler <fsateler <at> gmail.com> wrote:
> On 16 April 2015 at 06:23, Tanu Kaskinen <tanu.kaskinen <at> linux.intel.com> wrote:
>> On Thu, 2015-04-16 at 14:25 +0530, Arun Raghavan wrote:
>>> On 16 April 2015 at 14:23, Tanu Kaskinen <tanu.kaskinen <at> linux.intel.com> wrote:
>>> > On Wed, 2015-04-15 at 12:43 -0300, Felipe Sateler wrote:
>>> >> But some reasons for installing packages explicitly:
>>> >>
>>> >> 1. Not in build-dep (git-core, check)
>>> >> 2. Version upgrade after adding the trusty repositories. The build
>>> >> failed if I didn't upgrade the autotools before building (not sure
>>> >> why).
>>> >
>>> > So "apt-get build-dep" doesn't automatically upgrade all dependencies if
>>> > they're already installed? And you didn't want to do a full system
>>> > upgrade from 12.04 to 14.04.
>>> >
>>> >> 3. Me being lazy. dh-autoreconf is not used but I know it brings in
>>> >> all the required deps for running autotools (we use that in the debian
>>> >> package).
>>> >>
>>> >> Some pruning may be possible, but perhaps it is better to scrap the
>>> >> build-dep and be explicit on what is depended upon.
>>> >
>>> > Having an explicit list of the build dependencies seems like the best
>>> > way forward.
>>>
>>> I'm not a huge fan of this since we'd have to remember to update the
>>> file each time deps change. Using the Ubuntu packaging deps seems more
>>> pragmatic.
>>
>> Well, "apt-get build-dep" is great in theory, but it sounds like it may
>> result in some dependencies coming from 12.04 and some from 14.04,
>> because already-installed packages don't get updated, and according to
>> Felipe, that already caused problems with autotools. What do you think
>> would be the best way to solve this?
>
> I'd favor putting the whole list in the travis file. Advantages of doing so:
>
> 1. Tested documentation on required build dependencies.
> 2. Installing manually instead of build-dep makes apt upgrade the
> dependencies in question. Given that the base environment is 3 years
> old, we should be doing this anyway. Unfortunately, a dist-upgrade is
> not the best option for this since the environment is not quite
> pristine (I tried this and it failed).
> 3. No need to worry to keep in sync between what is in the ubuntu
> package vs upstream. Ubuntu might have some options disabled due to
> core/non-core distinctions (I believe that is why libweb-rtc is not
> enabled in ubuntu) or simply because the ubuntu release is too old.
>
> Also, we can just pick up the base from the ubuntu package so it is
> not much extra work either.

Okay, I'm game to go with this approach and see how it goes.

-- Arun
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Felipe Sateler | 15 Apr 01:32 2015
Picon

[PATCH] Add a .travis.yml for Travis CI

From: Arun Raghavan <arun <at> accosted.net>

Currently uses Ubuntu's build dependencies, and runs make check and
check-daemon.

Based on Arun Raghavan's travis file. Added trusty repositories to get
newer libs.
---
 .travis.yml | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 .travis.yml

For this to be run automatically someone that controls the pulseaudio
name in github must link the repository to travis.

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0000000..a869372
--- /dev/null
+++ b/.travis.yml
 <at>  <at>  -0,0 +1,21  <at>  <at> 
+language: c
+
+compiler:
+  - gcc
+ #- clang
+
+before_install:
+  - sudo sh -c 'echo "deb http://archive.ubuntu.com/ubuntu/ trusty main universe\ndeb-src
http://archive.ubuntu.com/ubuntu/ trusty main universe" >> /etc/apt/sources.list'
+  - sudo apt-get -qq update
+install:
+  - sudo apt-get -qq build-dep pulseaudio
+  - sudo apt-get -qq install libcap-dev libjson-c-dev autopoint git-core autoconf automake gcc
dh-autoreconf check intltool
+
+before_script:
+  # can't run git-version-gen on a shallow clone or without tags
+  - if [[ -a .git/shallow ]]; then git fetch --unshallow; fi
+  - git fetch --tags
+  - NOCONFIGURE=1 ./bootstrap.sh
+
+script:
+  - ./configure --localstatedir=/var && make && make check && make check-daemon
--

-- 
2.1.4

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Tanu Kaskinen | 13 Apr 16:25 2015
Picon

Patch review status wiki page updated

Patch review status updated:
http://www.freedesktop.org/wiki/Software/PulseAudio/PatchStatus/

Statistics:

* 2015-04-13
   * 74 patches are pending review.
   * The oldest pending patch is 267 days old.

* 2015-04-01
   * 80 patches are pending review.
   * The oldest pending patch is 255 days old.

* 2015-03-24
   * 70 patches are pending review.
   * The oldest pending patch is 247 days old.

* 2015-03-16
   * 45 patches are pending review.
   * The oldest pending patch is 239 days old.

* 2015-02-23
   * 25 patches are pending review.
   * The oldest pending patch is 218 days old.

* 2015-02-02
   * 22 patches are pending review
   * The oldest pending patch is 197 days old.

* 2015-01-28
   * 22 patches are pending review.
   * The oldest pending patch is 192 days old.

* 2015-01-19
   * 26 patches are pending review.
   * The oldest pending patch is 183 days old.

* 2015-01-13
   * 21 patches are pending review.
   * The oldest pending patch is 177 days old.

* 2015-01-08
   * 26 patches are pending review.
   * The oldest pending patch is 172 days old.

--

-- 
Tanu
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Radhakrishnan, Manjula (M. | 13 Apr 15:08 2015

Re: pulseaudio-discuss Digest, Vol 46, Issue 50

Hi,

Any comments/direction in the Performance issue with PA read and CPU consumption in idle state will be helpful.

Thanks & Regards

Manjula R
SME – Audio/DSP
Visteon Technical & Services Center , India
Phone: +91-44-49477829



-----Original Message-----
From: Radhakrishnan, Manjula (M.) 
Sent: Monday, March 16, 2015 10:48 AM
To: pulseaudio-discuss <at> lists.freedesktop.org
Subject: RE: pulseaudio-discuss Digest, Vol 46, Issue 50

Hi,

I have added my explanation below , is this a known limitation that writes to PA should occur only after read
has started , otherwise an initial delay will be seen ?  This is causing a major issue in embedded real time system.

Thanks & Regards

Manjula R
SME – Audio/DSP
Visteon Technical & Services Center , India
Phone: +91-44-49477829




------------------------------

Message: 3
Date: Thu, 26 Feb 2015 11:34:44 +0530
From: Arun Raghavan <arun <at> accosted.net>
To: General PulseAudio Discussion
	<pulseaudio-discuss <at> lists.freedesktop.org>
Subject: Re: [pulseaudio-discuss] PA- Performance issue with PA read
	and CPU consumption in idle state
Message-ID:
	<CACuU-+iC3=F94bR9tnZAh3T1Y7CQ5ydvwGa8Cac_No9TbSuiGg <at> mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 12 February 2015 at 19:33, Radhakrishnan, Manjula (M.) <rmanjula <at> visteon.com> wrote:
> Hi ,
>
> Thanks for the reply.
>
> The platform is based on ARM Cortex A9 core.
>
> Regarding the Issue 1  reported :
>
> On analyzing the pa_simple_read , the following observations are seen.
>
> The delay is casued by pa_stream_peek not retuned read length , not 
> clear on why this could fail since pa write has started.

Not sure what you mean here.

[rmanjula ] I have tried to explain the function in which the PA read is being blocked for a long time when PA
write has started much earlier.

> In pa_stream_peek , read length is returned as null , hence blocked at 
> "pa_threaded_mainloop_wait".
> It comes out of " pa_threaded_mainloop_wait" , and again fails at 
> pa_stream_peek.
> This looping happens between 5- 8 times then it returns successfully 
> from pa_simple_read.

It's pretty hard for me to say much about this without some sort of test case that I can reproduce here.

[rmanjula] The steps given below could reproduce the issue.  

If you're doing anything non-trivial, you probably want to use the async API, and not pa_simple_*(), btw.

[rmanjula] The PA is used only for data routing between processes and no other functionality of PA is used.
DATA from Process A to Process B through PA.

> We ran another test code to eliminate the influence of CPU or other
> application ,   The test script is as follows :
>
> 1.  paplay -droute_test /home/test441.wav          /*  route_test is a null
> sink , play audio to this null sink  */
> 2. sleep 1            /* sleep for 1 sec before read */
> 3. ./test_code.sh    /*  test code to read data from the null sink  , added
> time stamp to measure the duration inside pa_simpe_read */
>
> With the above script ,  the measured time inside first pa_simpe_read 
> is 1.8 sec
>
> The issue is not seen if paplay is immediately followed by PA read , 
> i.e
>
> 1.  paplay -droute_test /home/test441.wav      /* route_test is a null sink
> */
> 2. ./test_code.sh    /*  test code to read data from the null sink  , added
> time stamp to measure the duration inside pa_simpe_read */
>
> With this test , the measured time inside pa_simpe_read is few micro 
> seconds and  there is no block inside pa_simpe_read.
>
> when the test script was executed , no other major CPU consumption in 
> the core.
>
> We are trying to understand the impact of starting the pa write 
> earlier than pa read and the cause of this delay.
>
> The pa write instance is in an external application and operates 
> independently and the instance cannot be synchronised with pa read start.

Does this happen with parec as well? And if yes, is the behaviour on your desktop the same as on your device?

[rmanjula]  yes , the same behavior is seen with parec as well .

> 2.  On Issue 2 ,
>
> The input and output both are at 44.1 Khz and no resampling of audio 
> involved.  CPU is seen when there is no write/read hapenning.
>
> Is there any specific PA compile time options to be set for optimized CPU ?
> please let know .

In most cases, it'll all be automatically detected based on your -march flags, and what's available at run-time.

Cheers,
Arun


_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
arun | 13 Apr 11:26 2015
Picon

[PATCH] protocol-native: Fix source latency calculation in ADJUST_LATENCY mode

From: Arun Raghavan <git <at> arunraghavan.net>

This fixes buffer attr calculation so that we set the source latency to
the requested latency. This makes sense because the intermediate
delay_memblockq is just a mechanism to send data to the client. It
should not actually add to the total latency over what the source
already provides.

With this, the meaning of fragsize and maxlength become more
meaningful/accurate with regards to ADJUST_LATENCY mode -- fragsize
becomes the latency the source is configured for (which is then
approximately the total latency until the buffer reaches the client).
Maxlength, as before, continues to be the maximum amount of data we
might hold for the client before overrunning.
---
 src/pulsecore/protocol-native.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c
index adb5877..a5f4e23 100644
--- a/src/pulsecore/protocol-native.c
+++ b/src/pulsecore/protocol-native.c
 <at>  <at>  -568,11 +568,14  <at>  <at>  static void fix_record_buffer_attr_pre(record_stream *s) {
     } else if (s->adjust_latency) {

         /* So, the user asked us to adjust the latency according to
-         * what the source can provide. Half the latency will be
-         * spent on the hw buffer, half of it in the async buffer
-         * queue we maintain for each client. */
+         * what the source can provide. We set the source to whatever
+         * latency it can provide that is closest to what we want, and
+         * let the client buffer be equally large. This does NOT mean
+         * that we are doing (2 * fragsize) bytes of buffering, since
+         * the client-side buffer is only data that is on the way to
+         * the client. */

-        source_usec = fragsize_usec/2;
+        source_usec = fragsize_usec;

     } else {

 <at>  <at>  -598,12 +601,10  <at>  <at>  static void fix_record_buffer_attr_pre(record_stream *s) {

     } else if (s->adjust_latency) {

-        /* Now subtract what we actually got */
+        /* We keep the client buffer large enough to transfer one
+         * hardware-buffer-sized chunk at a time to the client. */

-        if (fragsize_usec >= s->configured_source_latency*2)
-            fragsize_usec -= s->configured_source_latency;
-        else
-            fragsize_usec = s->configured_source_latency;
+        fragsize_usec = s->configured_source_latency;
     }

     if (pa_usec_to_bytes(orig_fragsize_usec, &s->source_output->sample_spec) !=
--

-- 
2.1.0

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Gmane