date:20110324

On Tue, 2011-03-22 at 16:06 +0100, Maarten Bosmans wrote:
 Is there a better way than
 #if defined(__linux__)  !defined(__OPTIMIZE__)
 to check for a debug build? By default the CFLAGS contain -g -O2, so
 __OPTIMIZE__ will not be defined and running uninstalled does not
 work.

Lennart might be able to answer this better, but to me it sounds like we
should just drop the !__OPTIMIZE__ bit.

-- Arun

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] svolume_orc.c: error: line 67: unknown directive: .longparam

On Mon, 2011-03-21 at 00:06 +0100, Paul Menzel wrote:
 Dear PulseAudio folks,
[...]
 I guess it has something to do with
 
 commit 4cd90d9e32ca9a23e3c0f7615974ea0c55ff3e49
 Author: Arun Raghavan arun.ragha...@collabora.co.uk
 Date:   Mon Oct 25 17:59:08 2010 +0100
 
 volume: Add Orc-based optimised volume scaling
 
 This adds volume scaling for 1- and 2-channel software volume 
 scaling
 using Orc. While testing the MMX and SSE backends on a Core2, I 
 see an
 ~2x performance benefit over the hand-rolled MMX and SSE code. 
 Since I
 haven't been able to test on other architectures, the Orc code is 
 only
 used when MMX/SSE* is present. This can be changed in the future 
 after
 testing on AMD and ARM machines.
 
 but I do not know anything about this.
 
 I am using OpenEmbedded with `minimal` or `minimal-uclibc` for `MACHINE
 = at91sam9260ek`. ORCC 0.4.9 is used on this system.

Could you try with Orc 0.4.10? Unfortunately, I don't have a quick way
to downgrade my local Orc version to verify? If this is not possible, we
can just bump the patch to 0.4.11, which was released a while ago (and
is what I'm using).

BTW, for 0.9.22 and current stable-queue, the Orc stuff will not get
used for anything on ARM.

Cheers,
Arun

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

'Twas brillig, and Maarten Bosmans at 22/03/11 15:06 did gyre and gimble:
 Is there a better way than
 #if defined(__linux__)  !defined(__OPTIMIZE__)
 to check for a debug build? By default the CFLAGS contain -g -O2, so
 __OPTIMIZE__ will not be defined and running uninstalled does not
 work.

Do you mean __OPTIMIZE__ *will* be defined?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-24 Thread Kelly Anderson


Arun,

I've been trying to get higher bit rates to passthrough with no luck.  
Is setting the channel count supported with passthrough (yet)?


It seems that 384k sample rates aren't supported directly in alsa, I did 
some patching to no avail yet.


In any case if the channel count can be specified with passthrough the 
following should work.


paplay --raw --channels=2 --rate=192000 --passthrough 
File.dts.spdif192khz ( this works).


paplay --raw --channels=4 --rate=192000 --passthrough 
File.dts.spdif384khz ( this fails).


To passthrough dolby true-hd it looks like it'll be necessary for more 
than two channels to work.


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] More patches for OS X

'Twas brillig, and Daniel Mack at 22/03/11 12:14 did gyre and gimble:
 On Mon, Mar 21, 2011 at 12:39 AM, Daniel Mack zon...@gmail.com wrote:
 On Sun, Mar 20, 2011 at 6:39 PM, Daniel Mack zon...@gmail.com wrote:
 Hi,

 I'm catching up with my work on PulseAudio for OS X and have some
 patches ready I would like to get merged.

 Ok, I fixed all the minor issues that were reported and pushed out again.

 Same URL:

  git://github.com/zonque/pulseaudio.git osx
 
 Does anybody want me to resend the patches to the list or are you fine
 with checking them from the repository?

Merged in my tree now. As you know, the ML was having a wee rest, hence
the delay.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 0/2] Rebased bluetooth patches

'Twas brillig, and Tanu Kaskinen at 21/03/11 13:08 did gyre and gimble:
 Colin wrote:
 Can you rebase these two on git master please? I just merged a whole
 bunch of changes from BT guys and these both fail now.
 
 Sure, refreshed patches coming.
 
 Tanu Kaskinen (2):
   bluetooth: Don't log an error if an endpoint type is disabled.
   bluetooth: Get rid of warnings about unused stuff when building
 against a D-Bus version that doesn't have fd-passing support.
 
  src/modules/bluetooth/bluetooth-util.c |   43 
 +++-
  src/modules/bluetooth/bluetooth-util.h |2 +
  2 files changed, 33 insertions(+), 12 deletions(-)
 

Both in my tree now.

Thanks.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] win32: Simplify dl_search_path code

'Twas brillig, and Maarten Bosmans at 22/03/11 15:02 did gyre and gimble:
 And add #include sys/stat.h, needed by the code introduced in f7acd4bd.

In my tree now. Thanks

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

'Twas brillig, and Maarten Bosmans at 22/03/11 15:02 did gyre and gimble:
 To make the code cleaner and have the checks all in one place.

In my tree now.

Thanks

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

'Twas brillig, and Colin Guthrie at 24/03/11 09:02 did gyre and gimble:
 'Twas brillig, and Maarten Bosmans at 22/03/11 15:06 did gyre and gimble:
 Is there a better way than
 #if defined(__linux__)  !defined(__OPTIMIZE__)
 to check for a debug build? By default the CFLAGS contain -g -O2, so
 __OPTIMIZE__ will not be defined and running uninstalled does not
 work.
 
 Do you mean __OPTIMIZE__ *will* be defined?

Also, is there any way we can check to see if the binary being run is in
the build tree? Would that be an easier hack?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] Log feature: Correct bad function implementation

2011-03-24 Thread Vincent Becker

Replace wrong implementation of log to file in pa_daemon_conf_set_log_level to 
pa_daemon_conf_set_log_target

Signed-off-by: Vincent Becker vincentx.bec...@intel.com
---
 src/daemon/daemon-conf.c |   40 +++-
 1 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index 0d42f73..35935f9 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -142,8 +142,6 @@ static const pa_daemon_conf default_conf = {
 #endif
 };
 
-static int log_fd = -1;
-
 pa_daemon_conf* pa_daemon_conf_new(void) {
 pa_daemon_conf *c;
 
@@ -170,8 +168,7 @@ pa_daemon_conf* pa_daemon_conf_new(void) {
 void pa_daemon_conf_free(pa_daemon_conf *c) {
 pa_assert(c);
 
-if (log_fd = 0)
-pa_close(log_fd);
+pa_log_set_fd(-1);
 
 pa_xfree(c-script_commands);
 pa_xfree(c-dl_search_path);
@@ -192,7 +189,24 @@ int pa_daemon_conf_set_log_target(pa_daemon_conf *c, const 
char *string) {
 } else if (!strcmp(string, stderr)) {
 c-auto_log_target = 0;
 c-log_target = PA_LOG_STDERR;
-} else
+} else if (pa_startswith(string, file:)) {
+char file_path[512];
+int log_fd;
+
+pa_strlcpy(file_path, string + 5, sizeof(file_path));
+
+/* Open target file with user rights */
+if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
+ c-auto_log_target = 0;
+ c-log_target = PA_LOG_FD;
+ pa_log_set_fd(log_fd);
+}
+else {
+printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
+return -1;
+}
+}
+else
 return -1;
 
 return 0;
@@ -218,22 +232,6 @@ int pa_daemon_conf_set_log_level(pa_daemon_conf *c, const 
char *string) {
 c-log_level = PA_LOG_WARN;
 else if (pa_startswith(string, err))
 c-log_level = PA_LOG_ERROR;
-else if (pa_startswith(string, file:)) {
-char file_path[512];
-
-pa_strlcpy(file_path, string + 5, sizeof(file_path));
-
-/* Open target file with user rights */
-if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
- c-auto_log_target = 0;
- c-log_target = PA_LOG_FD;
- pa_log_set_fd(log_fd);
-}
-else {
-printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
-return -1;
-}
-}
 else
 return -1;
 
-- 
1.7.2.3

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

2011/3/24 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and Colin Guthrie at 24/03/11 09:02 did gyre and gimble:
 'Twas brillig, and Maarten Bosmans at 22/03/11 15:06 did gyre and gimble:
 Is there a better way than
 #if defined(__linux__)  !defined(__OPTIMIZE__)
 to check for a debug build? By default the CFLAGS contain -g -O2, so
 __OPTIMIZE__ will not be defined and running uninstalled does not
 work.

 Do you mean __OPTIMIZE__ *will* be defined?

Yes, of course, __OPTIMIZE__ is defined when compiling with -O2 and
the condition *will not* be true and running uninstalled does not
work.

 Also, is there any way we can check to see if the binary being run is in
 the build tree? Would that be an easier hack?

Well the actual check is in the body of that function:
pa_bool_t pa_run_from_build_tree(void) {
char *rp;
pa_bool_t b = FALSE;
if ((rp = pa_readlink(/proc/self/exe))) {
b = pa_startswith(rp, PA_BUILDDIR);
pa_xfree(rp);
}
return b;
}

I think only compiling that on developer builds and inlining return
FALSE for normal, e.g. distro builds makes sense. However __OPTIMIZE__
is not a good differentiator here.

 Col

Maarten
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Log feature: Correct bad function implementation

'Twas brillig, and Vincent Becker at 24/03/11 10:35 did gyre and gimble:
 Replace wrong implementation of log to file in pa_daemon_conf_set_log_level 
 to pa_daemon_conf_set_log_target

Sorry but this is not based on git master (as Maarten asked for before).

[colin@jimmy pulseaudio (master|AM)]$ cat ~/Download/pa.patch | patch
-p1 --dry-run
patching file src/daemon/daemon-conf.c
Hunk #1 FAILED at 142.
Hunk #2 FAILED at 170.
Hunk #3 succeeded at 187 (offset -5 lines).
Hunk #4 FAILED at 235.
3 out of 4 hunks FAILED -- saving rejects to file
src/daemon/daemon-conf.c.rej

I think it's just a matter of ignoring hunks 1  2 anyway (as I already
made that change when I committed the original version) and the move
from 4 to 3 should just be updated as the code in hunk 4 was updated
(tho' the newer code is the same as you put in in your hunk 3).

IOW, feel free to update your patch, or alternatively, I can just commit
what I have. (straight move of the code) which I've attached. Let me
know if it's OK.


Cheers

Col

PS, kinda embarrassed I missed this glaring error first time round :D



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
From 97ca39bd478250b423f1cefdabe757997b6e4459 Mon Sep 17 00:00:00 2001
From: Vincent Becker vincentx.bec...@intel.com
Date: Thu, 24 Mar 2011 11:35:02 +0100
Subject: [PATCH] log: Correct bad function implementation

Replace wrong implementation of log to file in pa_daemon_conf_set_log_level to 
pa_daemon_conf_set_log_target
---
 src/daemon/daemon-conf.c |   33 -
 1 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index 2872c74..30bea24 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -187,6 +187,22 @@ int pa_daemon_conf_set_log_target(pa_daemon_conf *c, const 
char *string) {
 } else if (!strcmp(string, stderr)) {
 c-auto_log_target = 0;
 c-log_target = PA_LOG_STDERR;
+} else if (pa_startswith(string, file:)) {
+char file_path[512];
+int log_fd;
+
+pa_strlcpy(file_path, string + 5, sizeof(file_path));
+
+/* Open target file with user rights */
+if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
+ c-auto_log_target = 0;
+ c-log_target = PA_LOG_FD;
+ pa_log_set_fd(log_fd);
+}
+else {
+printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
+return -1;
+}
 } else
 return -1;
 
@@ -213,23 +229,6 @@ int pa_daemon_conf_set_log_level(pa_daemon_conf *c, const 
char *string) {
 c-log_level = PA_LOG_WARN;
 else if (pa_startswith(string, err))
 c-log_level = PA_LOG_ERROR;
-else if (pa_startswith(string, file:)) {
-char file_path[512];
-int log_fd;
-
-pa_strlcpy(file_path, string + 5, sizeof(file_path));
-
-/* Open target file with user rights */
-if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
- c-auto_log_target = 0;
- c-log_target = PA_LOG_FD;
- pa_log_set_fd(log_fd);
-}
-else {
-printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
-return -1;
-}
-}
 else
 return -1;
 
-- 
1.7.4.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

On Thu, 2011-03-24 at 11:46 +0100, Maarten Bosmans wrote:
[...]
 I think only compiling that on developer builds and inlining return
 FALSE for normal, e.g. distro builds makes sense. However __OPTIMIZE__
 is not a good differentiator here.

The callers all seem to be initialisation routines only, so why not just
let it be called in distro and manual builds?

-- Arun

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util

'Twas brillig, and Arun Raghavan at 24/03/11 11:04 did gyre and gimble:
 On Thu, 2011-03-24 at 11:46 +0100, Maarten Bosmans wrote:
 [...]
 I think only compiling that on developer builds and inlining return
 FALSE for normal, e.g. distro builds makes sense. However __OPTIMIZE__
 is not a good differentiator here.
 
 The callers all seem to be initialisation routines only, so why not just
 let it be called in distro and manual builds?

That's kinda what I was thinking too. It's only a couple extra checks at
startup, so it's probably not a massive deal overall to leave this check
in for distro builds, tho' I agree it would be nice to miss it out if
possible not sure there is such a way :s

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
all resulting in the same volume change.
---
 src/utils/pactl.c |   98 +---
 1 files changed, 62 insertions(+), 36 deletions(-)

diff --git a/src/utils/pactl.c b/src/utils/pactl.c
index ad5c0b8..672bfbb 100644
--- a/src/utils/pactl.c
+++ b/src/utils/pactl.c
@@ -65,6 +65,12 @@ static uint32_t module_index;
 static pa_bool_t suspend;
 static pa_bool_t mute;
 static pa_volume_t volume;
+enum volume_type {
+VOL_SW,
+VOL_PERCENT,
+VOL_LINEAR,
+VOL_DECIBEL
+};
 
 static pa_proplist *proplist = NULL;
 
@@ -956,6 +962,54 @@ static void exit_signal_callback(pa_mainloop_api *m, 
pa_signal_event *e, int sig
 quit(0);
 }
 
+static int parse_volume(const char *vol_spec, pa_volume_t *vol) {
+int volume_type = VOL_SW;
+double v;
+char *vs;
+
+pa_assert(vol_spec);
+pa_assert(vol);
+
+vs = pa_xstrdup(vol_spec);
+
+for (char *c = vs; *c; c++) {
+  if (*c == '.')
+volume_type = VOL_LINEAR;
+}
+if (pa_endswith(vs, %)) {
+volume_type = VOL_PERCENT;
+vs[strlen(vs)-1] = 0;
+}
+if (pa_endswith(vs, db) || pa_endswith(vs, dB)) {
+volume_type = VOL_DECIBEL;
+vs[strlen(vs)-2] = 0;
+}
+
+if (pa_atod(vs, v)  0) {
+pa_log(_(Invalid volume specification));
+pa_xfree(vs);
+return -1;
+}
+
+pa_xfree(vs);
+
+if (volume_type == VOL_PERCENT)
+v = v * (double) PA_VOLUME_NORM / 100;
+if (volume_type == VOL_LINEAR)
+v = pa_sw_volume_from_linear(v);
+if (volume_type == VOL_DECIBEL)
+v = pa_sw_volume_from_dB(v);
+
+if (!PA_VOLUME_IS_VALID((pa_volume_t) v)) {
+pa_log(_(Volume outside permissible range.\n));
+return -1;
+}
+
+*vol = (pa_volume_t) v;
+
+return 0;
+}
+
 static void help(const char *argv0) {
 
 printf(_(%s [options] stat\n
@@ -1235,7 +1289,6 @@ int main(int argc, char *argv[]) {
 port_name = pa_xstrdup(argv[optind+2]);
 
 } else if (pa_streq(argv[optind], set-sink-volume)) {
-uint32_t v;
 action = SET_SINK_VOLUME;
 
 if (argc != optind+3) {
@@ -1243,21 +1296,12 @@ int main(int argc, char *argv[]) {
 goto quit;
 }
 
-if (pa_atou(argv[optind+2], v)  0) {
-pa_log(_(Invalid volume specification));
-goto quit;
-}
+sink_name = pa_xstrdup(argv[optind+1]);
 
-if (!PA_VOLUME_IS_VALID(v)) {
-pa_log(_(Volume outside permissible range.\n));
+if (parse_volume(argv[optind+2], volume)  0)
 goto quit;
-}
-
-sink_name = pa_xstrdup(argv[optind+1]);
-volume = (pa_volume_t) v;
 
 } else if (pa_streq(argv[optind], set-source-volume)) {
-uint32_t v;
 action = SET_SOURCE_VOLUME;
 
 if (argc != optind+3) {
@@ -1265,21 +1309,12 @@ int main(int argc, char *argv[]) {
 goto quit;
 }
 
-if (pa_atou(argv[optind+2], v)  0) {
-pa_log(_(Invalid volume specification));
-goto quit;
-}
+source_name = pa_xstrdup(argv[optind+1]);
 
-if (!PA_VOLUME_IS_VALID(v)) {
-pa_log(_(Volume outside permissible range.\n));
+if (parse_volume(argv[optind+2], volume)  0)
 goto quit;
-}
-
-source_name = pa_xstrdup(argv[optind+1]);
-volume = (pa_volume_t) v;
 
 } else if (pa_streq(argv[optind], set-sink-input-volume)) {
-uint32_t v;
 action = SET_SINK_INPUT_VOLUME;
 
 if (argc != optind+3) {
@@ -1292,17 +1327,8 @@ int main(int argc, char *argv[]) {
 goto quit;
 }
 
-if (pa_atou(argv[optind+2], v)  0) {
-pa_log(_(Invalid volume specification));
-goto quit;
-}
-
-if (!PA_VOLUME_IS_VALID(v)) {
-pa_log(_(Volume outside permissible range.\n));
+if (parse_volume(argv[optind+2], volume)  0)
 goto quit;
-}
-
-volume = (pa_volume_t) v;
 
 } else if (pa_streq(argv[optind], set-sink-mute)) {
 int b;
@@ -1314,7 +1340,7 @@ int main(int argc, char *argv[]) {
 }
 
 if ((b = pa_parse_boolean(argv[optind+2]))  0) {
-pa_log(_(Invalid volume specification));
+pa_log(_(Invalid mute specification));
 goto quit;
 }
 
@@ -1331,7 +1357,7 @@ int main(int argc, char *argv[]) {
 }
 
 if ((b = pa_parse_boolean(argv[optind+2]))  0) {
-pa_log(_(Invalid volume specification));
+pa_log(_(Invalid mute specification));
 goto quit;
 }

[pulseaudio-discuss] [PATCH 2/2] pactl: Add subcommands to the list command

---
 src/utils/pactl.c |   62 +++-
 1 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/src/utils/pactl.c b/src/utils/pactl.c
index 672bfbb..11ddcb3 100644
--- a/src/utils/pactl.c
+++ b/src/utils/pactl.c
@@ -48,6 +48,7 @@ static pa_context *context = NULL;
 static pa_mainloop_api *mainloop_api = NULL;
 
 static char
+*list_type = NULL,
 *sample_name = NULL,
 *sink_name = NULL,
 *source_name = NULL,
@@ -834,15 +835,37 @@ static void context_state_callback(pa_context *c, void 
*userdata) {
 break;
 
 case LIST:
-actions = 8;
-pa_operation_unref(pa_context_get_module_info_list(c, 
get_module_info_callback, NULL));
-pa_operation_unref(pa_context_get_sink_info_list(c, 
get_sink_info_callback, NULL));
-pa_operation_unref(pa_context_get_source_info_list(c, 
get_source_info_callback, NULL));
-pa_operation_unref(pa_context_get_sink_input_info_list(c, 
get_sink_input_info_callback, NULL));
-
pa_operation_unref(pa_context_get_source_output_info_list(c, 
get_source_output_info_callback, NULL));
-pa_operation_unref(pa_context_get_client_info_list(c, 
get_client_info_callback, NULL));
-pa_operation_unref(pa_context_get_sample_info_list(c, 
get_sample_info_callback, NULL));
-pa_operation_unref(pa_context_get_card_info_list(c, 
get_card_info_callback, NULL));
+if (list_type) {
+actions = 1;
+if (pa_streq(list_type, modules))
+
pa_operation_unref(pa_context_get_module_info_list(c, get_module_info_callback, 
NULL));
+else if (pa_streq(list_type, sinks))
+
pa_operation_unref(pa_context_get_sink_info_list(c, get_sink_info_callback, 
NULL));
+else if (pa_streq(list_type, sources))
+
pa_operation_unref(pa_context_get_source_info_list(c, get_source_info_callback, 
NULL));
+else if (pa_streq(list_type, sink-inputs))
+
pa_operation_unref(pa_context_get_sink_input_info_list(c, 
get_sink_input_info_callback, NULL));
+else if (pa_streq(list_type, source-outputs))
+
pa_operation_unref(pa_context_get_source_output_info_list(c, 
get_source_output_info_callback, NULL));
+else if (pa_streq(list_type, clients))
+
pa_operation_unref(pa_context_get_client_info_list(c, get_client_info_callback, 
NULL));
+else if (pa_streq(list_type, samples))
+
pa_operation_unref(pa_context_get_sample_info_list(c, get_sample_info_callback, 
NULL));
+else if (pa_streq(list_type, cards))
+
pa_operation_unref(pa_context_get_card_info_list(c, get_card_info_callback, 
NULL));
+else
+pa_assert_not_reached();
+} else {
+actions = 8;
+pa_operation_unref(pa_context_get_module_info_list(c, 
get_module_info_callback, NULL));
+pa_operation_unref(pa_context_get_sink_info_list(c, 
get_sink_info_callback, NULL));
+pa_operation_unref(pa_context_get_source_info_list(c, 
get_source_info_callback, NULL));
+
pa_operation_unref(pa_context_get_sink_input_info_list(c, 
get_sink_input_info_callback, NULL));
+
pa_operation_unref(pa_context_get_source_output_info_list(c, 
get_source_output_info_callback, NULL));
+pa_operation_unref(pa_context_get_client_info_list(c, 
get_client_info_callback, NULL));
+pa_operation_unref(pa_context_get_sample_info_list(c, 
get_sample_info_callback, NULL));
+pa_operation_unref(pa_context_get_card_info_list(c, 
get_card_info_callback, NULL));
+}
 break;
 
 case MOVE_SINK_INPUT:
@@ -1013,7 +1036,7 @@ static int parse_volume(const char *vol_spec, pa_volume_t 
*vol) {
 static void help(const char *argv0) {
 
 printf(_(%s [options] stat\n
- %s [options] list\n
+ %s [options] list [TYPE]\n
  %s [options] exit\n
  %s [options] upload-sample FILENAME [NAME]\n
  %s [options] play-sample NAME [SINK]\n
@@ -1050,7 +1073,7 @@ enum {
 };
 
 int main(int argc, char *argv[]) {
-pa_mainloop* m = NULL;
+pa_mainloop *m = NULL;
 int ret = 1, c;
 char *server = NULL, *bn;
 
@@ -1114,10 +1137,25 @@ int main(int argc, char *argv[]) {
 if (optind  argc) {
 if (pa_streq(argv[optind], stat))
 action

Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
 With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
 all resulting in the same volume change.

I was also going to add relative volumes, such as +3dB and -5%, by
detecting a + or - sign in the volume. But that clashes with the
absolute dB scale (insofar a dB can ever be absolute) that can also be
negative.

Any suggestions for graceful handling of this?

Maarten
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble:
 2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
 With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
 all resulting in the same volume change.
 
 I was also going to add relative volumes, such as +3dB and -5%, by
 detecting a + or - sign in the volume. But that clashes with the
 absolute dB scale (insofar a dB can ever be absolute) that can also be
 negative.
 
 Any suggestions for graceful handling of this?

How about if the first letter of the volume change is an i or a d
then this indicated increment or decrement relative volume?

It's not as clean as the +/- labelling sadly but such is life.

Alternatively your absolute dB volumes could be specified as 60-dB or
7+dB (where 7dB implies 7+dB)... That way the prefix +/- notation
could be used for relative adjustments. The only downside there is that
setting absolute dB volumes is more confusing (you'd never need to use
anything other than XdB for relative adjustments anyway).

Personally I'd go for the later as I think relative adjustments are
probably more common, so it's syntax should be neatest, but I could be
very wrong :D

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

Adjusting the sample rate is done in the IO thread, which can cause
interruptions in the audio if the adjustment requires heavy computation. The
trivial resampler is guaranteed to be light on the cpu.

It would be better to adjust the sample rate in some other thread (FWIW,
module-combine uses the main thread), but this quick hack fixes the immediate
problem of spending too much time in the IO thread.
---
 src/modules/module-loopback.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/modules/module-loopback.c b/src/modules/module-loopback.c
index 9a8640b..3ade248 100644
--- a/src/modules/module-loopback.c
+++ b/src/modules/module-loopback.c
@@ -714,6 +714,7 @@ int pa__init(pa_module *m) {
 pa_sink_input_new_data_set_sample_spec(sink_input_data, ss);
 pa_sink_input_new_data_set_channel_map(sink_input_data, map);
 sink_input_data.flags = PA_SINK_INPUT_VARIABLE_RATE;
+sink_input_data.resample_method = PA_RESAMPLER_TRIVIAL;
 
 sink_dont_move = FALSE;
 if (pa_modargs_get_value_boolean(ma, sink_dont_move, sink_dont_move)  
0) {
-- 
1.7.4.1

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen tanu.kaski...@digia.com wrote:
 Adjusting the sample rate is done in the IO thread, which can cause
 interruptions in the audio if the adjustment requires heavy computation. The
 trivial resampler is guaranteed to be light on the cpu.

 It would be better to adjust the sample rate in some other thread (FWIW,
 module-combine uses the main thread), but this quick hack fixes the immediate
 problem of spending too much time in the IO thread.

I don't think it's the right or only way to solve the problem. If you
are using the loopback and SRC is required, the assumption is that you
don't care too much about latency. If the audio events are spaced
enough, there should be plenty of time to run the resampling. we
should instead adjust the sink/source latencies to reduce the number
of events and not compromize on quality.
This trivial resampler should only be used if for some reason you want
both real-time behavior and low-latency while using an SRC. I fail to
see in what cases you would care? In what practical cases did you
encounter underflows?
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] Log feature: Correct bad function implementation

2011-03-24 Thread Vincent Becker

Replace wrong implementation of log to a file in pa_daemon_conf_set_log_level 
to pa_daemon_conf_set_log_target

Signed-off-by: Vincent Becker vincentx.bec...@intel.com
---
 src/daemon/daemon-conf.c |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index 2872c74..8b10c0d 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -187,7 +187,24 @@ int pa_daemon_conf_set_log_target(pa_daemon_conf *c, const 
char *string) {
 } else if (!strcmp(string, stderr)) {
 c-auto_log_target = 0;
 c-log_target = PA_LOG_STDERR;
-} else
+} else if (pa_startswith(string, file:)) {
+char file_path[512];
+int log_fd;
+
+pa_strlcpy(file_path, string + 5, sizeof(file_path));
+
+/* Open target file with user rights */
+if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
+ c-auto_log_target = 0;
+ c-log_target = PA_LOG_FD;
+ pa_log_set_fd(log_fd);
+}
+else {
+printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
+return -1;
+}
+}
+else
 return -1;
 
 return 0;
@@ -213,23 +230,6 @@ int pa_daemon_conf_set_log_level(pa_daemon_conf *c, const 
char *string) {
 c-log_level = PA_LOG_WARN;
 else if (pa_startswith(string, err))
 c-log_level = PA_LOG_ERROR;
-else if (pa_startswith(string, file:)) {
-char file_path[512];
-int log_fd;
-
-pa_strlcpy(file_path, string + 5, sizeof(file_path));
-
-/* Open target file with user rights */
-if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, S_IRWXU)) = 0) {
- c-auto_log_target = 0;
- c-log_target = PA_LOG_FD;
- pa_log_set_fd(log_fd);
-}
-else {
-printf(Failed to open target file %s, error : %s\n, file_path, 
pa_cstrerror(errno));
-return -1;
-}
-}
 else
 return -1;
 
-- 
1.7.2.3

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

On Thu, 2011-03-24 at 15:31 +0200, pl bossart wrote:
 On Thu, Mar 24, 2011 at 8:16 AM, Tanu Kaskinen tanu.kaski...@digia.com 
 wrote:
  Adjusting the sample rate is done in the IO thread, which can cause
  interruptions in the audio if the adjustment requires heavy computation. The
  trivial resampler is guaranteed to be light on the cpu.
 
  It would be better to adjust the sample rate in some other thread (FWIW,
  module-combine uses the main thread), but this quick hack fixes the 
  immediate
  problem of spending too much time in the IO thread.
 
 I don't think it's the right or only way to solve the problem. If you
 are using the loopback and SRC is required, the assumption is that you
 don't care too much about latency. If the audio events are spaced
 enough, there should be plenty of time to run the resampling. we
 should instead adjust the sink/source latencies to reduce the number
 of events and not compromize on quality.

Aren't you assuming here that the resampling adjustment timeout happens
right after the buffers are filled, and never when the buffer is running
low and a refill is scheduled right after the adjustment timeout?

 This trivial resampler should only be used if for some reason you want
 both real-time behavior and low-latency while using an SRC. I fail to
 see in what cases you would care? In what practical cases did you
 encounter underflows?

The sink may be running in a low-latency mode even if the loopback
stream doesn't have any latency requirements - there may be other
streams active at the same time with stricter timing requirements.

FWIW, the practical case here was a very simple test of looping null
sink's monitor to a hw sink with default settings on Harmattan. It may
be that our setup is more suspectible to this kind of problems than
normal systems, but I still think that non-realtime-safe stuff should
be kept out of the IO threads, regardless of the setup, especially if
such stuff can very well be done outside the IO thread.

-- 
Tanu

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Log feature: Correct bad function implementation

2011-03-24 Thread Becker, VincentX

-Original Message-
From: Colin Guthrie [mailto:gm...@colin.guthr.ie]
Sent: Thursday, March 24, 2011 12:02 PM
To: General PulseAudio Discussion
Cc: Becker, VincentX
Subject: Re: [PATCH] Log feature: Correct bad function implementation

'Twas brillig, and Vincent Becker at 24/03/11 10:35 did gyre and gimble:
 Replace wrong implementation of log to file in
 pa_daemon_conf_set_log_level to pa_daemon_conf_set_log_target

Sorry but this is not based on git master (as Maarten asked for
before).

[colin@jimmy pulseaudio (master|AM)]$ cat ~/Download/pa.patch | patch
-p1 --dry-run
patching file src/daemon/daemon-conf.c
Hunk #1 FAILED at 142.
Hunk #2 FAILED at 170.
Hunk #3 succeeded at 187 (offset -5 lines).
Hunk #4 FAILED at 235.
3 out of 4 hunks FAILED -- saving rejects to file src/daemon/daemon-
conf.c.rej

I think it's just a matter of ignoring hunks 1  2 anyway (as I already
made that change when I committed the original version) and the move
from 4 to 3 should just be updated as the code in hunk 4 was updated
(tho' the newer code is the same as you put in in your hunk 3).

Sorry I am still learning with git. I thought that taking the code as-is was 
enough. I have just sent a patch back to you from master branch, and it should 
be OK, I hope.

Vin

IOW, feel free to update your patch, or alternatively, I can just commit
what I have. (straight move of the code) which I've attached. Let me
know if it's OK.

Cheers

Col

PS, kinda embarrassed I missed this glaring error first time round :D

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/] Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

 The sink may be running in a low-latency mode even if the loopback
 stream doesn't have any latency requirements - there may be other
 streams active at the same time with stricter timing requirements.

 FWIW, the practical case here was a very simple test of looping null
 sink's monitor to a hw sink with default settings on Harmattan. It may
 be that our setup is more suspectible to this kind of problems than
 normal systems, but I still think that non-realtime-safe stuff should
 be kept out of the IO threads, regardless of the setup, especially if
 such stuff can very well be done outside the IO thread.

if you are still using 10ms periods on the hw sinks, then yes it's an
artifical use case in a constrained environment that doesn't use
timer-based scheduling...
I don't disagree that doing SRC in an io thread is not that kosher,
but keep in mind that we also do mixing and volume control in the IO
thread. There is some amount of DSP in this thread which will impact
response time to hw events.
Maybe your idea of linking latency with SRC quality makes sense. I
feel however that the speex SRC is not up to snuff and results in high
CPU usage. If we fixed the SRC to use a 'reasonable' MHz figure this
problem would go away.

Loopback is used in Medfield for FM playback only. I haven't heard of
any issues. The only bugs on loopback I've seen are on erratic src
adjustments on BT A2DP and RTP RX, but I haven't tried since Maarten
contributed patches.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

It seems that 384k sample rates aren't supported directly in alsa, I did
some patching to no avail yet.

In any case if the channel count can be specified with passthrough the
following should work.

paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz (
this works).

paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz (
this fails).

To passthrough dolby true-hd it looks like it'll be necessary for more than
two channels to work.

There was a thread on dts-hd in alsa-devel at some point. Anssi
(cc:ed) contributed some patches for HDMI and provided the information
below on ffmpeg configurations.
You may want to try at the alsa level before trying with pulseaudio to
make sure your setup is correct. I tend to believe you have to go for
8ch @ 192kHz to make this work based on my limited understanding of
HBR.
-Pierre

The DTS-HD part is not merged yet (patch is in ffmpeg-devel@), but the
TrueHD and E-AC-3 support is already there in ffmpeg trunk.

The ffmpeg commandline to use is:
ffmpeg -i input.file -f spdif output.spdif

For DTS-HD files, to get full passthrough (i.e. not only core), a
-dtshd_rate parameter is needed, which sets the output IEC958 rate.
ffmpeg -i input.file -f spdif -dtshd_rate 192000 output.spdif
ffmpeg -i input.file -f spdif -dtshd_rate 768000 output.spdif
192000Hz is enough for streams that have a bitrate below 6.144Mbps, which
means all DTS-HD High Resolution Audio files and even many of the DTS-HD
Master Audio (the latter are lossless VBR).

To play the spdif files back, I use
aplay -D hdmi:CARD=$CARDNAME,DEV=$DEVICENUM,AES0=0x06 -c $CHANCOUNT -r
$RATE file.spdif

- replacing $CARDNAME with the card name
- replacing $DEVICENUM with 0..3 depending on card and hdmi port (for
non-zero DEVICENUM you'll need a patch from alsa git:
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60
)
- set $CHANCOUNT and $RATE as per below
- rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz
E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg)
- rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD
files, and for DTS-HD when the rate was set to 768000)
- note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when
$CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use
HBR or not. The additional 0x04 (non-copyright) I use above is not
mandatory, but is the alsa default so I kept it.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC PATCH] Log PCM samples to files

2011-03-24 Thread Becker, VincentX

-Original Message-
From: Maarten Bosmans [mailto:mkbosm...@gmail.com]
Sent: Wednesday, March 23, 2011 7:44 PM
To: General PulseAudio Discussion
Cc: Becker, VincentX
Subject: Re: [pulseaudio-discuss] [RFC PATCH] Log PCM samples to files

2011/3/21 Vincent Becker vincentx.bec...@intel.com:
 Hi,

 I recently created a new PA module (module-log-pcm) which is able to
log PCM samples from any source/sink and its corresponding
outputs/inputs. For testing audio quality, checking signal processing or   
verifying the right implementation of a sound device mixed in PA,
application fields are many.

What is the use case you are specifically interested in?

It can just be any use case that is related to audio and Pulseaudio. I am 
particulary interested to log audio before and after sound algorithms to check 
that the signal processing has been well applied (or filters).

 One just needs to give a parameter list depending on what is wished to
be logged. During the process, an audio tree, or parts of it, is probed
and logged for post-treatment purposes.

I'm sorry if I am being stuped here, but wat can the module do that
you can't with parec from a monitor source?

The module does the exact same thing as parec but parec can just log one device 
at a time but not the inputs and/or outputs.
If you wanted to log the whole set of sinks/sources connected to Pulse, you 
would need to run as many parec commands as there are devices. Not very 
practical though.
With the module you can specify a list of sinks or sources and choose to log 
the inputs or outputs, thing that is impossible now with Pulseaudio. Ok that 
needs a modification in the Pulsecore 
to probe the chunks when they are peeked or pushed but I don't see any other 
way.

 For design needs, sources and sinks are designated by ends and
source outputs/sink inputs by ports.

Why introduce the new terminology here? I think it is confusing for
people that know pulse already. Or is there perhaps some subtle
difference between the pulse concept and your designation for it?

Just to group sinks and sources under one word, same for inputs/outputs. It 
does not exist in Pulseaudio, am I right? So it shouldn't confuse anybody, I 
hope.

I am pretty sure that this module can be useful, especially when big sets of 
sinks/sources are present and someone wants to analyze an audio tree part of 
these sets during a specific use case. Why not ? May be it will create some 
needs at least..

Maarten
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Log feature: Correct bad function implementation

'Twas brillig, and Becker, VincentX at 24/03/11 13:51 did gyre and gimble:
 Sorry but this is not based on git master (as Maarten asked
 for before).
 
 [colin@jimmy pulseaudio (master|AM)]$ cat ~/Download/pa.patch |
 patch -p1 --dry-run patching file src/daemon/daemon-conf.c Hunk #1
 FAILED at 142. Hunk #2 FAILED at 170. Hunk #3 succeeded at 187
 (offset -5 lines). Hunk #4 FAILED at 235. 3 out of 4 hunks FAILED
 -- saving rejects to file src/daemon/daemon- conf.c.rej
 
 I think it's just a matter of ignoring hunks 1  2 anyway (as I
 already made that change when I committed the original version) and
 the move from 4 to 3 should just be updated as the code in hunk 4
 was updated (tho' the newer code is the same as you put in in your
 hunk 3).
 
 
 Sorry I am still learning with git. I thought that taking the code
 as-is was enough. I have just sent a patch back to you from master
 branch, and it should be OK, I hope.

Yeah that's fine. It's more or less the same as the one I attached last
time but with a couple minor formatting differences.

I've pushed a slightly modified version (both from my last one and your
one!) just to be annoying ;)

I only change some bracketing and log message formatting, so totally
trivial.

Thanks for the fix ups :)

I'll try and look at the second patch to do with optimising the actual
log writing sometime very soon.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

On Thu, 2011-03-24 at 13:07 +, Colin Guthrie wrote:
 'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble:
  2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
  With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
  all resulting in the same volume change.
  
  I was also going to add relative volumes, such as +3dB and -5%, by
  detecting a + or - sign in the volume. But that clashes with the
  absolute dB scale (insofar a dB can ever be absolute) that can also be
  negative.
  
  Any suggestions for graceful handling of this?
 
 How about if the first letter of the volume change is an i or a d
 then this indicated increment or decrement relative volume?
 
 It's not as clean as the +/- labelling sadly but such is life.
 
 Alternatively your absolute dB volumes could be specified as 60-dB or
 7+dB (where 7dB implies 7+dB)... That way the prefix +/- notation
 could be used for relative adjustments. The only downside there is that
 setting absolute dB volumes is more confusing (you'd never need to use
 anything other than XdB for relative adjustments anyway).
 
 Personally I'd go for the later as I think relative adjustments are
 probably more common, so it's syntax should be neatest, but I could be
 very wrong :D

Or maybe just do this as a separate set-volume-step command (or
-increment or something better named)?

-- Arun

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

On Thu, 2011-03-24 at 22:22 +0530, Arun Raghavan wrote:
 On Thu, 2011-03-24 at 13:07 +, Colin Guthrie wrote:
  'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble:
   2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
   With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
   all resulting in the same volume change.
   
   I was also going to add relative volumes, such as +3dB and -5%, by
   detecting a + or - sign in the volume. But that clashes with the
   absolute dB scale (insofar a dB can ever be absolute) that can also be
   negative.
   
   Any suggestions for graceful handling of this?
  
  How about if the first letter of the volume change is an i or a d
  then this indicated increment or decrement relative volume?
  
  It's not as clean as the +/- labelling sadly but such is life.
  
  Alternatively your absolute dB volumes could be specified as 60-dB or
  7+dB (where 7dB implies 7+dB)... That way the prefix +/- notation
  could be used for relative adjustments. The only downside there is that
  setting absolute dB volumes is more confusing (you'd never need to use
  anything other than XdB for relative adjustments anyway).
  
  Personally I'd go for the later as I think relative adjustments are
  probably more common, so it's syntax should be neatest, but I could be
  very wrong :D
 
 Or maybe just do this as a separate set-volume-step command (or
 -increment or something better named)?

I agree - I think a separate command is a good idea. For command naming,
I suggest increase-sink-volume and decrease-sink-volume.

-- 
Tanu

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

On Thu, 2011-03-24 at 09:09 -0500, pl bossart wrote:
  The sink may be running in a low-latency mode even if the loopback
  stream doesn't have any latency requirements - there may be other
  streams active at the same time with stricter timing requirements.
 
  FWIW, the practical case here was a very simple test of looping null
  sink's monitor to a hw sink with default settings on Harmattan. It may
  be that our setup is more suspectible to this kind of problems than
  normal systems, but I still think that non-realtime-safe stuff should
  be kept out of the IO threads, regardless of the setup, especially if
  such stuff can very well be done outside the IO thread.
 
 if you are still using 10ms periods on the hw sinks, then yes it's an
 artifical use case in a constrained environment that doesn't use
 timer-based scheduling...
 I don't disagree that doing SRC in an io thread is not that kosher,
 but keep in mind that we also do mixing and volume control in the IO
 thread. There is some amount of DSP in this thread which will impact
 response time to hw events.

It might be that you have misunderstood the reason for the patch. Now
that I read the patch description again, it indeed isn't entirely clear:
the problem that I'm having is that the periodic (every 10 seconds)
reinitialization of the resampler takes too much CPU time. The
resampling itself is fine - I don't think it's even possible to move
that out of the IO thread, or if it's possible, it probably wouldn't
bring any benefits.

-- 
Tanu

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] loopback: Always use the trivial resampler.

 It might be that you have misunderstood the reason for the patch. Now
 that I read the patch description again, it indeed isn't entirely clear:
 the problem that I'm having is that the periodic (every 10 seconds)
 reinitialization of the resampler takes too much CPU time. The
 resampling itself is fine - I don't think it's even possible to move
 that out of the IO thread, or if it's possible, it probably wouldn't
 bring any benefits.

ok, makes more sense now. Could it be that this reinitialization isn't
optimized for your platform (Assuming it's Armv7-Neon?)
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats

'Twas brillig, and Tanu Kaskinen at 24/03/11 18:31 did gyre and gimble:
 On Thu, 2011-03-24 at 22:22 +0530, Arun Raghavan wrote:
 On Thu, 2011-03-24 at 13:07 +, Colin Guthrie wrote:
 'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble:
 2011/3/24 Maarten Bosmans mkbosm...@gmail.com:
 With this you can specify the volume with 6554, 10%, 0.001 or -60dB,
 all resulting in the same volume change.

 I was also going to add relative volumes, such as +3dB and -5%, by
 detecting a + or - sign in the volume. But that clashes with the
 absolute dB scale (insofar a dB can ever be absolute) that can also be
 negative.

 Any suggestions for graceful handling of this?

 How about if the first letter of the volume change is an i or a d
 then this indicated increment or decrement relative volume?

 It's not as clean as the +/- labelling sadly but such is life.

 Alternatively your absolute dB volumes could be specified as 60-dB or
 7+dB (where 7dB implies 7+dB)... That way the prefix +/- notation
 could be used for relative adjustments. The only downside there is that
 setting absolute dB volumes is more confusing (you'd never need to use
 anything other than XdB for relative adjustments anyway).

 Personally I'd go for the later as I think relative adjustments are
 probably more common, so it's syntax should be neatest, but I could be
 very wrong :D

 Or maybe just do this as a separate set-volume-step command (or
 -increment or something better named)?
 
 I agree - I think a separate command is a good idea. For command naming,
 I suggest increase-sink-volume and decrease-sink-volume.

While I think this is a valid solution, I'd prefer to see a single
command for the volume adjustment (change-sink-volume?) but use the +/-
notation. When we're talking relative adjustments the problem of how the
+'s and -'s are interpreted is gone anyway, so this is possible.

But I'm not overly fussed so if two commands for inc+dec is easier then
so be it.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] Several fixes to Pulseaudio's Vala bindings

2011-03-24 Thread Alexander Kurtz

Hi,

I have attached a patch with several small fixes to PA's Vala bindings:
Let me explain my changes:

 1. PA uses Vala's ``Posix'' package (see line 23 of libpulse.vapi). 
These dependencies have to be declared in the *.deps file. 

 2. Fix obvious CP error. 

 3. Rename the parameter to match the C function. This simplifies 
understanding what this parameter means. 

 4. According to the official documentation[1] the ``dev'' parameter 
may be NULL as this is the default. Change the method definition 
accordingly.

If you don't have any objections, please merge this patch into master.

Best regards

Alexander Kurtz

[1] 
http://0pointer.de/lennart/projects/pulseaudio/doxygen/stream_8h.html#ab9544f6677af133fbe81bf8a21eb489c
diff -Naur old/vala/libpulse.deps new/vala/libpulse.deps
--- old/vala/libpulse.deps	1970-01-01 01:00:00.0 +0100
+++ new/vala/libpulse.deps	2011-03-21 21:00:13.513867865 +0100
@@ -0,0 +1 @@
+posix
diff -Naur old/vala/libpulse.vapi new/vala/libpulse.vapi
--- old/vala/libpulse.vapi	2011-03-20 23:31:50.0 +0100
+++ new/vala/libpulse.vapi	2011-03-21 21:07:43.850868270 +0100
@@ -237,7 +237,7 @@
 [CCode (cname=PA_CHANNELS_MAX)]
 public const int CHANNELS_MAX;
 
-[CCode (cname=PA_CHANNELS_MAX)]
+[CCode (cname=PA_RATE_MAX)]
 public const int RATE_MAX;
 
 [CCode (cname=pa_cvolume)]
@@ -854,7 +854,7 @@
 public int iterate(bool block = true, out int retval = null);
 public int run(out int retval = null);
 public unowned MainLoopApi get_api();
-public void quit(int r);
+public void quit(int retval);
 public void wakeup();
 public void set_poll_func(PollFunc poll_func);
 }
@@ -1194,8 +1194,8 @@
 public int is_suspended();
 public int is_corked();
 
-public int connect_playback(string dev, BufferAttr? a = null, Flags flags = 0, CVolume? volume = null, Stream? sync_stream = null);
-public int connect_record(string dev, BufferAttr? a = null, Flags flags = 0);
+public int connect_playback(string? dev = null, BufferAttr? a = null, Flags flags = 0, CVolume? volume = null, Stream? sync_stream = null);
+public int connect_record(string? dev = null, BufferAttr? a = null, Flags flags = 0);
 public int connect_upload(size_t length);
 public int disconnect();
 public int finish_upload();


signature.asc
Description: This is a digitally signed message part
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Current problems with git master

'Twas brillig, and Colin Guthrie at 28/02/11 20:26 did gyre and gimble:
 2. Startup is no longer atomic:
 
 With PA not running and autospawn disabled:
  [colin@jimmy ~]$ start-pulseaudio-x11
  Connection failure: Connection refused
  pa_context_connect() failed: Connection refused
 
 PA does actually start but it's the pactl load-module's that cause this
 connection refused error. This means that pulseaudio --start returns
 before the daemon is ready for connections. This may also be something
 that is affecting the stable-queue (as I have heard of some startup
 races but never been able to reproduce).

OK, I've found when this problem was introduced and it was way back in:

commit 8e94f653489a0b3d549e61840a5cec711d466ab7
Author: Lennart Poettering lenn...@poettering.net
Date:   Sat Oct 31 02:43:47 2009 +0100

daemon: make sure pa has its own session and process group, but is
not its leader so that we cannot acquire a tty ever


which I think I've fixed in:

commit d47a33775b55877b9df42add3346779bba077299
Author: Colin Guthrie cguth...@mandriva.org
Date:   Thu Mar 24 21:27:55 2011 +

daemon: Fix regression with --start introduced with the double fork
in 8e94f653

The previous commit intoduced a double fork which caused a more or
less immediate
successful return prior to the hard work of actually starting a daemon.

This patch simply used pipe() to only signal our father when the
daemon really
has finished starting.


If someone could double check, I'd appreciate it (seeing as I'd rather
any bugs in my commit last less than a year and a half!!)


Col







-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or 'attribute' before 'X'

2011-03-24 Thread Paul Menzel

Dear PulseAudio folks,


I get the following error with latest master (a9c8f904).

  CC libbluetooth_sbc_la-sbc.lo
In file included from modules/bluetooth/sbc/sbc_primitives_armv6.h:30:0,
 from modules/bluetooth/sbc/sbc_math.h:27,
 from modules/bluetooth/sbc/sbc.c:46:
modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', 
';', '}' or '__attribute__' before 'X'
modules/bluetooth/sbc/sbc.c: In function 'sbc_synthesize_four':
modules/bluetooth/sbc/sbc.c:577:18: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:577:18: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:589:51: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c: In function 'sbc_synthesize_eight':
modules/bluetooth/sbc/sbc.c:619:29: warning: declaration of 'tmp' 
shadows a previous local [-Wshadow]
modules/bluetooth/sbc/sbc.c:619:29: warning: shadowed declaration is 
here [-Wshadow]
modules/bluetooth/sbc/sbc.c:619:29: warning: declaration of 'tmp' 
shadows a

Re: [pulseaudio-discuss] [PATCH] Several fixes to Pulseaudio's Vala bindings

'Twas brillig, and Alexander Kurtz at 24/03/11 21:06 did gyre and gimble:
 Hi,
 
 I have attached a patch with several small fixes to PA's Vala bindings:
 Let me explain my changes:
 
  1. PA uses Vala's ``Posix'' package (see line 23 of libpulse.vapi). 
 These dependencies have to be declared in the *.deps file. 
 
  2. Fix obvious CP error. 
 
  3. Rename the parameter to match the C function. This simplifies 
 understanding what this parameter means. 
 
  4. According to the official documentation[1] the ``dev'' parameter 
 may be NULL as this is the default. Change the method definition 
 accordingly.
 
 If you don't have any objections, please merge this patch into master.
 
 Best regards
 
 Alexander Kurtz

Thanks for the fixes :)

I've pushed this along with a tweak to the Makefile.am to install the
.deps file.

http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=705cf4d3164befffeb927e05d9f0f4402e9f80c4

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] PA Roadmap Planning and LAC Conference

2011-03-24 Thread Kurt Taylor

Hi all, I was wondering what happed with the LAC meetup. Were any plans
firmed up to have a pulseaudio working session before/after LAC?

Kurt Taylor (irc krtaylor)

On 19 February 2011 00:40, Arun Raghavan arun.ragha...@collabora.co.ukwrote:

 On Fri, 2011-02-18 at 23:00 +0200, Tanu Kaskinen wrote:
  On Fri, 2011-02-18 at 11:15 -0600, Kurt Taylor wrote:
   Thanks for organizing this Colin!  I will do my best to attend, but
 that is
   5am (UTC-6) for me.
 
  It sounds like a few hours later would be better than the suggested
  11:00 UTC. Arun would probably be the first person to be annoyed by the
  time being moved too much forward, but he's going to sleep at 21:30 UTC,
  so there's plenty of headroom :)

 :) Indeed. If it helps, I created a little webthingummy to get
 everyone's preferences (we can add more options, but it seemed to me
 24th was acceptable to all):

 http://www.doodle.com/ivx28di2kzztm2dt

 Cheers,
 Arun

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] PA Roadmap Planning and LAC Conference

'Twas brillig, and Kurt Taylor at 24/03/11 23:21 did gyre and gimble:
 Hi all, I was wondering what happed with the LAC meetup. Were any plans
 firmed up to have a pulseaudio working session before/after LAC?

Nothing formal arranged as of yet, but I'll be going, open to timing
suggestions.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or 'attribute' before 'X'

Well you are lucky to even compile, I get a bad dependency with git master.

 CCLD   libbluetooth-ipc.la
make[3]: *** No rule to make target `modules/bluetooth/sbc.c', needed by
`libbluetooth_sbc_la-sbc.lo'.  Stop.

[ume@plb pulseaudio]$ git bisect bad
e4eb4670108ad2b4a0d9c3044e12ed0d933f834e is the first bad commit
commit e4eb4670108ad2b4a0d9c3044e12ed0d933f834e
Author: Luiz Augusto von Dentz luiz.dentz-...@nokia.com
Date:   Mon Mar 14 14:46:10 2011 -0300

build: move sbc related files to its own directory

This should make it easier to apply patches from BlueZ which also uses
sbc subdir for this files.


Went back to before the sbc updates.
-Pierre
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [WIP] Passthrough support

2011-03-24 Thread Dark Shadow

On Thu, Mar 24, 2011 at 10:50 AM, Anssi Hannula anssi.hann...@iki.fi wrote:
On 24.03.2011 16:18, pl bossart wrote:
It seems that 384k sample rates aren't supported directly in alsa, I did
some patching to no avail yet.

In any case if the channel count can be specified with passthrough the
following should work.

paplay --raw --channels=2 --rate=192000 --passthrough File.dts.spdif192khz (
this works).

paplay --raw --channels=4 --rate=192000 --passthrough File.dts.spdif384khz (
this fails).

To passthrough dolby true-hd it looks like it'll be necessary for more than
two channels to work.

Indeed for HBR you need to always specify 8 channels and use rate to
control the final rate (i.e. you either use normal 2 channel
passthrough or HBR 8 channel passthrough).

For example to passthrough the abovementioned 384 kHz stream you need to
use 8 channels and rate of 96000. However, I think 384kHz DTS bitstream
is generally *not* supported by A/V receivers, so you probably want to
use 768kHz (8 channels, 192kHz).

(note: I haven't tested whether HBR works with pulseaudio or not)

The DTS-HD part is not merged yet (patch is in ffmpeg-devel@), but the
TrueHD and E-AC-3 support is already there in ffmpeg trunk.

The ffmpeg commandline to use is:
ffmpeg -i input.file -f spdif output.spdif

To play the spdif files back, I use
aplay -D hdmi:CARD=$CARDNAME,DEV=$DEVICENUM,AES0=0x06 -c $CHANCOUNT -r
$RATE file.spdif

--
Anssi Hannula
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Would anyone know where I could get a hold of some DTS-HD samples in
192Khz and 384kHz for testing?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or 'attribute' before 'X'