Re: [pulseaudio-discuss] [PATCH] modules: Disable timer scheduling for a2dp playback to reduce power consumption.

2014-10-22 Thread Alexander E. Patrakov

05.08.2014 11:35, Sajeesh Sidharthan wrote:

---
  src/modules/bluetooth/module-bluez5-device.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/modules/bluetooth/module-bluez5-device.c 
b/src/modules/bluetooth/module-bluez5-device.c
index 57b2791..eda7a9d 100644
--- a/src/modules/bluetooth/module-bluez5-device.c
+++ b/src/modules/bluetooth/module-bluez5-device.c
@@ -1170,10 +1170,10 @@ static void thread_func(void *userdata) {
  a2dp_reduce_bitpool(u);
  }
  }
-
-do_write = 1;
-pending_read_bytes = 0;
  }
+
+do_write = 1;
+pending_read_bytes = 0;
  }

  if (writable  do_write  0) {
@@ -1208,7 +1208,7 @@ static void thread_func(void *userdata) {
  sleep_for = PA_USEC_PER_MSEC * 500;

  pa_rtpoll_set_timer_relative(u-rtpoll, sleep_for);
-disable_timer = false;
+/* disable_timer = false; *//* Disable timer to reduce 
power consumption */
  }
  }
  }



I have tested this patch.

Both with and without this patch, using Wine (which always requests 
tlength=40.00 ms, minreq=10.00 ms unless patched with winepulse, which 
is something that e.g. Arch does not do), I have:


I: [pulseaudio] protocol-native.c: Final latency 99.03 ms = 39.52 ms + 
2*10.00 ms + 39.51 ms


Without this patch, Wine somehow marginally manages to work, with some 
Skipping 7119 us (= 1252 bytes) in audio stream messages in the 
pulseaudio log. With this patch, it just produces a lot of xruns.


--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


[pulseaudio-discuss] [PATCH] pavucontrol: Handle IO errors in icon setting code

2014-10-22 Thread Felipe Sateler
If gtk cannot load the file, it may throw a Gio::Error. In that case
fall back to setting the name.

BugLink: https://bugs.debian.org/765725
---
 src/mainwindow.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mainwindow.cc b/src/mainwindow.cc
index 5d205fb..ff0011c 100644
--- a/src/mainwindow.cc
+++ b/src/mainwindow.cc
@@ -251,6 +251,8 @@ static void set_icon_name_fallback(Gtk::Image *i, const 
char *name, Gtk::IconSiz
 i-set(name);
 } catch (Gtk::IconThemeError e) {
 i-set(name);
+} catch (Gio::Error e) {
+i-set(name);
 }
 }
 
-- 
2.1.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


[pulseaudio-discuss] [PATCH] Don't crash if pa_stream_peek returns NULL

2014-10-22 Thread Felipe Sateler
From: Christer Stenbrenden chris...@uggwar.net

pa_stream_peek can return NULL if either the buffer is empty or if it
has a hole. In either case we need to avoid derefencing the data
pointer. Additionally, if there is a hole, we need to call pa_stream_drop,
if the buffer is empty we should not call it.

Thanks to Christer Stenbrenden for the initial patch.
BugLink: https://bugs.debian.org/735898
---
 src/mainwindow.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mainwindow.cc b/src/mainwindow.cc
index 5d205fb..ff9ec52 100644
--- a/src/mainwindow.cc
+++ b/src/mainwindow.cc
@@ -493,6 +493,14 @@ static void read_callback(pa_stream *s, size_t length, 
void *userdata) {
 return;
 }
 
+if (!data) {
+// NULL data means either a hole or empty buffer.
+   // Only drop the stream when there is a hole (length  0)
+if (length)
+pa_stream_drop(s);
+return;
+}
+
 assert(length  0);
 assert(length % sizeof(float) == 0);
 
-- 
2.1.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms

2014-10-22 Thread Raymond Yau

 Of course, this only applies to ALSA devices that can't use tsched, as
 well as to OSS on more exotic platforms.

 This is needed for compatibility with Wine games that use DirectSound8
 on distributions such as Arch Linux who don't accept the unofficial
 winepulse patch. The reason is that Wine DirectSound8 emulation requests
 a period of 10 ms and expects it to work for the purposes of timing. And
 in fact, it cannot know (via ALSA API) that it is not going to work!

 A known malware-free test application is Foobar2000 version 1.2. Later
 versions no longer use DirectSound.

 This issue is not going to be fixed on the Wine side, because the audio
 subsystem in Wine is not really maintained, and the maintainer has
 already privately expressed some negative thoughts about the state of
 the linux audio ecosystem in general.

 The correct solution (at least from the isolate the clients from
 hardware limitations as thoroughly as possible viewpoint) would be to
 consume audio from sink inputs using a timer if the actual sink does not
 provide sufficiently small minreq. In other words, adapt tsched to BATCH
 cards and drop non-tsched. But that's a whole project. So, as a stopgap
 solution for running Wine games on e.g. USB audio (which is a topic that
 pops up regularly on #pulseaudio IRC channel), let's reduce the default
 fragment size to a value suitable for unpatched Wine.

 Regarding the value: on my system, for mp3 playback through Foobar2000,
 8ms fragments work, 9ms fragments result in constant underruns.

 Wine wiki recommends 5ms.


 Maybe it should be made clearer that the actual periods may differ
slightly from the default settings due to hardware constraints or rounding
issues, e.g. with your 5ms setting at 44100 Hz the period of 220.5 samples
is going to be rounded



 On devices that can use tsched, there is no problem.

 Signed-off-by: Alexander E. Patrakov patra...@gmail.com
 ---
   man/pulse-daemon.conf.5.xml.in | 4 ++--
   src/daemon/daemon-conf.c   | 2 +-
   src/daemon/daemon.conf.in  | 2 +-
   3 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/man/pulse-daemon.conf.5.xml.in b/man/
pulse-daemon.conf.5.xml.in
 index 8bd076d..ff54435 100644
 --- a/man/pulse-daemon.conf.5.xml.in
 +++ b/man/pulse-daemon.conf.5.xml.in
 @@ -463,8 +463,8 @@ USA.
   /option
   option
 poptdefault-fragment-size-msec=/optThe duration of a
 -  single fragment. Defaults to 25ms (i.e. the total buffer is thus
 -  100ms long)./p
 +  single fragment. Defaults to 5ms (i.e. the total buffer is thus
 +  20ms long)./p
   /option

 /section
 diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
 index b7a85aa..6dc15cf 100644
 --- a/src/daemon/daemon-conf.c
 +++ b/src/daemon/daemon-conf.c
 @@ -96,7 +96,7 @@ static const pa_daemon_conf default_conf = {
   .lock_memory = false,
   .deferred_volume = true,
   .default_n_fragments = 4,
 -.default_fragment_size_msec = 25,
 +.default_fragment_size_msec = 5,


 I've never understood why 4 fragments would be needed. Use 2 fragments
and 10ms periods...

For drivers can report hwptr only on period boundary, you cannot perform
any rewind safely when using two periods

This mean read/write must also in period size too

Even when driver can report hwptr position in every dma brust transfer, the
hwptr position still have an uncertainity of dma brust size
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms

2014-10-22 Thread Raymond Yau

 Of course, this only applies to ALSA devices that can't use tsched, as
 well as to OSS on more exotic platforms.

 This is needed for compatibility with Wine games that use DirectSound8
 on distributions such as Arch Linux who don't accept the unofficial
 winepulse patch. The reason is that Wine DirectSound8 emulation requests
 a period of 10 ms and expects it to work for the purposes of timing. And
 in fact, it cannot know (via ALSA API) that it is not going to work!

 A known malware-free test application is Foobar2000 version 1.2. Later
 versions no longer use DirectSound.

 This issue is not going to be fixed on the Wine side, because the audio
 subsystem in Wine is not really maintained, and the maintainer has
 already privately expressed some negative thoughts about the state of
 the linux audio ecosystem in general.

 The correct solution (at least from the isolate the clients from
 hardware limitations as thoroughly as possible

It is the hardware limitation affect the low latency,
this mean that pulseaudio have to select the maximum of lowest latency of
all the sinks / sources as default latency

viewpoint) would be to
 consume audio from sink inputs using a timer if the actual sink does not
 provide sufficiently small minreq. In other words, adapt tsched to BATCH
 cards and drop non-tsched. But that's a whole project. So, as a stopgap
 solution for running Wine games on e.g. USB audio (which is a topic that
 pops up regularly on #pulseaudio IRC channel), let's reduce the default
 fragment size to a value suitable for unpatched Wine.

 Regarding the value: on my system, for mp3 playback through Foobar2000,
 8ms fragments work, 9ms fragments result in constant underruns.

 Wine wiki recommends 5ms.

 On devices that can use tsched, there is no problem.


 diff --git a/man/pulse-daemon.conf.5.xml.inb/man/
pulse-daemon.conf.5.xml.in
 index 8bd076d..ff54435 100644
 --- a/man/pulse-daemon.conf.5.xml.in
 +++ b/man/pulse-daemon.conf.5.xml.in
 @@ -463,8 +463,8 @@ USA.
  /option
  option
poptdefault-fragment-size-msec=/optThe duration of a
 -  single fragment. Defaults to 25ms (i.e. the total buffer is thus
 -  100ms long)./p
 +  single fragment. Defaults to 5ms (i.e. the total buffer is thus
 +  20ms long)./p
  /option


Is it feasible to add an alternative parameter in fragment size since some
soc driver does not support disable period wakep but dma brust sizes
require 8 frames ?

https://bugs.freedesktop.org/show_bug.cgi?id=84585
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] Problem with timing and USB scanning...

2014-10-22 Thread Joshua J. Kugler
On Thursday, October 23, 2014 13:13:19 Raymond Yau wrote:
 Unfotunately, you need to fix many things in kernel

Well, I'm an end user, not a kernel hacker, so I don't see it getting fixed any 
time soon. :)

 Is this a notebook with internal 5.1 speakers with three jacks at rear
 panel (headphone , mic and line in) ?

Notebook: yes
Internal 5.1? I don't believe so.
Headphone, mic, line in? Yes.

 1) large volume range of mic capture
 Volume and speaker playback volume
 
 
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/usb/mixer.c?id=9b4ef97757953c6071563b7cbfc689e3dd771603

Are you saying there is a large range on the internal mic? or on the USB mic?

 2) your 5.1 internal speaker have same priority
Which priority are we discussing?  Somewhere in udev?  In pulse audio? Or in 
the KDE audio setup?  And this original thread wasn't about speakers.  The USB 
out works fine, every time.  My issue is this: when I try to hotplug the USB 
headset, it comes up as a *output* device only, instead of also detecting the 
mic.

Also, this worked flawlessly in Ubuntu 12.04 (pulse-audio 1.1, kernel 3.2-3.8). 
It is only since upgrading to pulse-audio 4.0 and kernel 3.13.x that i have a 
problem.

j


-- 
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss