date:20111020

Re: [pulseaudio-discuss] Pulse and audio settings

2011-10-20 Thread Robert Orzanna

Why would you want to adjust these settings outside of pulseaudio and
in what way do the sliders in pavucontrol not suffice?

I don't see any way how to adjust PCM which by default is set to 100
by pulseaudio. Hence, I must use alsamixer to reduce the distortions
caused by the high PCM.

Then your distro is broken.

Following Maartens response it is not, and overwriting alsa settings is a
normal behaviour of pulse.

The alsa-utils packages ensures that alsa mixer values are saved on


shutdown and restored at boot up. It's saved in asound.state which is
kept in /var (nowadays).

The latest alsa-utils even ships with systemd units to do this for you.
Prior to standardisation with systemd, various different distros handled
this differently so you'll have to ask your distro people about it.

Ultimately tho', if you fire up an alsa mixer and make some changes, and
run: sudo alsactl store, it should wirte the file
/var/lib/alsa/asound.state. Similarly sudo alsactl restore should read
that state file and apply it.

Of course I can run alsactl restore after pulseaudio had completely
started. But this is only a workaround since it is obviously not
indented to overwrite pulse settings.

Regards

2011/10/19 Robert Orzanna orsch...@googlemail.com

 Hello,

 With the new version of pulse (1.0-4) I hoped that pulse will somehow take
 care of my alsa settings which still is not the case.

 All settings, for example set with alsamixer, are discarded after reboot.

 Now I wonder what's the best way to define some settings such as mic and
 PCM level with pulse when pavucontrol does not offer such possibilities?

 Regards,

  Robert

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

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

2011-10-20 Thread Tanu Kaskinen

On Wed, 2011-10-19 at 19:56 -0400, Chris wrote:
 OK, in my quest to get the output of one application to be used as the
 input for another, I got module-null-sink all set
 
 from list short sinks
 9 vac module-null-sink.c  s16le 2ch 44100Hz   SUSPENDED
 
 from list short sources
 12vac.monitor module-null-sink.c  s16le 2ch 44100Hz   
 SUSPENDED
 
 My two applications recognize ALSA devices.
 
 One of them for example sees the following options for output devices
 
 Audio Output Devices:
 id: 0 - hw:HDA ATI SB,0
 id: 1 - hw:HDA ATI SB,1
 id: 2 - hw:HD-Audio Generic,3
 id: 4 - hw:USB Audio CODEC,0

Are those all of the options? Those refer only to the raw hw: devices,
which are not suitable to be used with Pulseaudio. There should at least
be one option that refers to the device named default, otherwise I
don't think there's any hope of getting this to work.

In case you are somehow able to use those non-hw devices like default,
you can define alsa devices yourself. For example, the default device
is usually directed to Pulseaudio, and it's defined with a configuration
snippet something like this (should be done by your distribution, but
you can also put this to ~/.asoundrc):

pcm.!default {
type pulse
}

(That exclamation mark means that this definition will override the
older definition for default if it happens to have been defined
already in some other configuration file). That alsa device will use
whatever sink Pulseaudio thinks is best. For making alsa devices for the
null sink and its monitor, this should work:

pcm.vac {
type pulse
device vac
}

pcm.vacmonitor {
type pulse
device vac.monitor
}

-- 
Tanu

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

Re: [pulseaudio-discuss] [PATCH] alsa-card: Handle the profile modarg.

2011-10-20 Thread Arun Raghavan

On Thu, 2011-10-20 at 09:52 +0300, Tanu Kaskinen wrote:
 On Thu, 2011-10-20 at 09:33 +0530, Arun Raghavan wrote:
  On Mon, 2011-10-03 at 18:11 +0300, Tanu Kaskinen wrote:
   ---
  
  Pulled to my tree with a fix to the commit message since I'd like to
  (somewhat) standardise the namespaces for commit messages.
 
 Do you mean that you'd like to only ever use alsa as the commit prefix
 for anything alsa related? I don't really like that - I think the
 precision for example with alsa-card is useful. The information could
 be added to the main part of the commit message, for example alsa:
 Handle the profile modarg in module-alsa-card, but I don't see any real
 improvement in that. And in this case the message is reasonably short,
 but often you have to work harder to make the headline reasonably brief,
 and the prefix usually can express things more concisely than the
 natural language of the main headline sentence. What are the benefits
 of limiting the number of available prefixes?

I did go with the same thing that you suggested. Same information, but
keeps a standard prefix.

There's nothing concrete at the moment that will be aided by this
consistency, but at some point it might be handy to be able to group
messages by such prefixes (for reporting/statistics, fancier
shortlogs, ...).

-- Arun

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

Re: [pulseaudio-discuss] [PATCH] Remove time-smoother and shm from libpulsecore

2011-10-20 Thread Maarten Bosmans

2011/10/20 Arun Raghavan arun.ragha...@collabora.co.uk:
 On Wed, 2011-10-19 at 14:10 +0200, Maarten Bosmans wrote:
 As they are already included in libpulsecommon.
 ---

 AFAICT, time-smoother.h is used in libpulse (pa_stream_get_time), but
 shm.h is not, so shouldn't be in pulsecommon.

But shm.h is used in pulsecore/memblock.c, which is in libpulsecommon,
so it should also be.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] fix two warnings in utils/padsp.c

2011-10-20 Thread Maarten Bosmans

2011/10/20 Arun Raghavan arun.ragha...@collabora.co.uk:
 On Tue, 2011-10-18 at 14:48 +0800, Lu Guanqun wrote:
 CC     libpulsedsp_la-padsp.lo
 utils/padsp.c:1524:5: warning: no previous prototype for '__open_2' 
 [-Wmissing-prototypes]
 utils/padsp.c:2560:5: warning: no previous prototype for '__open64_2' 
 [-Wmissing-prototypes]
 ---
  src/utils/padsp.c |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/src/utils/padsp.c b/src/utils/padsp.c
 index a8bc8d2..414ebe4 100644
 --- a/src/utils/padsp.c
 +++ b/src/utils/padsp.c
 @@ -64,6 +64,9 @@
  #undef open
  #undef open64

 +int __open_2(const char *filename, int flags);
 +int __open64_2(const char *filename, int flags);
 +

 These two are defined a little later from where you've added them. Is
 this really present in master?

I also see these warnings from time to time, but not always. IIRC also
in master. But I haven't really been able to pinpoint exactly where
the problem lies. Until that time, I don't think just adding these is
a solution.

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

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

2011-10-20 Thread Maarten Bosmans

2011/10/20 Arun Raghavan arun.ragha...@collabora.co.uk:
 On Tue, 2011-10-18 at 12:10 +0200, Maarten Bosmans wrote:
  2011/10/18 Wang Xingchao xingchao.w...@intel.com:
  if all channels have same volume setting, use fast way to
  do volume change. this patch intended to work for two formats:
  s16ne/s16re.
 [...]
 The Orc svolume implementation currently only handles 1ch s16ne (the
 orcify branch also adds 1ch float), so I added a similar test for
 identical channel volumes for the Orc case:
 https://github.com/mkbosmans/pulseaudio/commit/8659d08f22ccaba0c1ca18c0b29744318bf4fe08
 I like that way (only using one extra variable) a bit better than
 yours (with both same_vol and fast_vol added), but that is not really
 important.

 Were you referring to the code in master? That handles both 1ch and 2ch.

Indeed, you're right, that's just me typing in stuff from memory
without looking it up.
Although the distinction I was trying to make was between s16 and float.

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

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

2011-10-20 Thread Maarten Bosmans

2011/10/20 Arun Raghavan arun.ragha...@collabora.co.uk:
 On Tue, 2011-10-18 at 17:09 -0400, Wang Xingchao wrote:
 if all channels have same volume setting, use fast way to
 do volume change. this patch intended to work for two formats:
 s16ne/s16re.

 Signed-off-by: Wang Xingchao xingchao.w...@intel.com
 ---

 As Tanu points out, some hard data here would be good. But just to set
 your expectations correctly, this code is actually not used on any
 recent x86 or ARM machine since there are optimised routines for these.
 I'm certainly not against optimisations to these paths, since
 there /are/ other architectures that PA runs on.

That's only for s16. And actually that exact same optimisation
(treating the stream as mono if all channel volumes are equal) could
also work for the assembly functions, just as I had already added it
to the Orc functions in my orcify branch.

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

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

2011-10-20 Thread Wang Xingchao

Hey Maarten,

I checked some code of your branch, thanks you have done so much work
in svolume part. And especially svolume-test is really very powerful
and worth for try. i decide to use it as the tool to check whether the
optimization is correct.

meanwhile, i met some compile error in branch remotes/origin/orcify,
could you help take a glance if you met same error before?

  CC libpulsecommon_UNKNOWN.UNKNOWN_la-client-conf.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-fork-detect.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-xmalloc.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-proplist.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-utf8.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-channelmap.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-sample.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-util.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-timeval.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-rtclock.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-authkey.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-conf-parser.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-error.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-rtclock.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-util.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-dynarray.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-flist.lo
  CC libpulsecommon_UNKNOWN.UNKNOWN_la-hashmap.lo
make[3]: *** No rule to make target `pulse/i18n.c', needed by
`libpulsecommon_UNKNOWN.UNKNOWN_la-i18n.lo'.  Stop.

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

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

2011-10-20 Thread Arun Raghavan

On Wed, 2011-10-19 at 13:11 +0300, Tanu Kaskinen wrote:
 On Wed, 2011-10-19 at 13:00 +0300, Colin Guthrie wrote:
  'Twas brillig, and David Henningsson at 18/10/11 20:56 did gyre and gimble:
   While in general I agree that a boolean is a fine success/failure return
   type, I think in Pulseaudio the convention is to stick just to ints.
   
   Hmm. A quick 'grep -r return TRUE' of PulseAudio source tree seems to
   give enough results to falsify that assumption.
 
 That gives a big list indeed. But did you check the context? I went
 through quite a lot (but not nearly all) of the output from 'git grep -n
 -e return TRUE -e return FALSE' and the overwhelming majority of the
 cases were from functions of which whole purpose is to give a yes/no
 answer, or where the function may or may not have a side effect (ie.
 where a nothing happened case is not an error). There were some cases
 where return FALSE really meant that an error happened, but most of
 those were from the recent format stuff...
 
  We're quite happy to return bools on internal stuff. It's just when
  dealing with client-site/public APIs that we stick to ints.
  
  So as this is an internal function, I think it's fine.
 
 It's not about having a portable ABI, it's only about the convention
 that errors are reported as negative integers. But if nobody else cares,
 then I'm fine too with using bools.

I usually only code with a negative value return on failure if the
callee can/should distinguish between different types of errors.

-- Arun

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

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

2011-10-20 Thread Arun Raghavan

On Wed, 2011-10-12 at 12:40 +0200, David Henningsson wrote:
 Note: There is still no notification when status availability changes.
 
 Signed-off-by: David Henningsson david.hennings...@canonical.com
 ---
[...]
 diff --git a/PROTOCOL b/PROTOCOL
 index 8c69190..b8b61e4 100644
 --- a/PROTOCOL
 +++ b/PROTOCOL
 @@ -278,6 +278,13 @@ New field in PA_COMMAND_UNDERFLOW:
  
  int64_t index
  
 +## v24, implemented by = 2.0
 +
 +New field in all commands that send/receive port introspection data
 +(PA_COMMAND_GET_(SOURCE|SINK)_INFO, PA_COMMAND_GET_(SOURCE|SINK)_INFO_LIST]):
 +
 +uint32_t available
 +

Is there a reason for this to be larger than uint8_t?

   If you just changed the protocol, read this
  ## module-tunnel depends on the sink/source/sink-input/source-input protocol
  ## internals, so if you changed these, you might have broken module-tunnel.

Does module-tunnel need to care about any of this?

[...]
 [diff --git a/src/pulse/def.h b/src/pulse/def.h
 index f43e864..8a74fad 100644
 --- a/src/pulse/def.h
 +++ b/src/pulse/def.h
 @@ -967,6 +967,21 @@ typedef void (*pa_free_cb_t)(void *p);
   * playback, \since 1.0 */
  #define PA_STREAM_EVENT_FORMAT_LOST format-lost
  
 +/** Port availability / jack detection status
 + * \since 2.0 */
 +typedef enum pa_port_available {
 +PA_PORT_AVAILABLE_UNKNOWN = 0, /** This port does not support jack 
 detection \since 2.0 */
 +PA_PORT_AVAILABLE_NO = 1,  /** This port is not available, likely 
 because the jack is not plugged in. \since 2.0 */
 +PA_PORT_AVAILABLE_YES = 2, /** This port is available, likely 
 because the jack is plugged in. \since 2.0 */
 +} pa_port_available_t;
 +
 +/** \cond fulldocs */
 +#define PA_PORT_AVAILABLE_UNKNOWN PA_PORT_AVAILABLE_UNKNOWN
 +#define PA_PORT_AVAILABLE_NO PA_PORT_AVAILABLE_NO
 +#define PA_PORT_AVAILABLE_YES PA_PORT_AVAILABLE_YES

I'd drop the likely because since that's going to depend on other bits
of implementation (for example a jack maybe unavailable on the current
profile and your comment will only be true if there's a policy module to
switch profiles on jack insertion).

 diff --git a/src/pulse/introspect.h b/src/pulse/introspect.h
 index 1d77d45..7732736 100644
 --- a/src/pulse/introspect.h
 +++ b/src/pulse/introspect.h
 @@ -202,6 +202,7 @@ typedef struct pa_sink_port_info {
  const char *name;   /** Name of this port */
  const char *description;/** Description of this port */
  uint32_t priority;  /** The higher this value is the 
 more useful this port is as a default */
 +pa_port_available_t available;  /** PA_PORT_AVAILABLE_UNKNOWN, 
 PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */
  } pa_sink_port_info;
  
  /** Stores information about sinks. Please note that this structure
 @@ -281,6 +282,7 @@ typedef struct pa_source_port_info {
  const char *name;   /** Name of this port */
  const char *description;/** Description of this port */
  uint32_t priority;  /** The higher this value is the 
 more useful this port is as a default */
 +pa_port_available_t available;  /** PA_PORT_AVAILABLE_UNKNOWN, 
 PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */
  } pa_source_port_info;

I think the docs already link to the enum type, so the long comment
might be replaced by Whether the port is available or not or something
similar.

[...]
 diff --git a/src/pulsecore/sink.h b/src/pulsecore/sink.h
 index 7f639e2..39ca117 100644
 --- a/src/pulsecore/sink.h
 +++ b/src/pulsecore/sink.h
 @@ -60,6 +60,7 @@ struct pa_device_port {
  char *description;
  
  unsigned priority;
 +pa_port_available_t available; /** PA_PORT_AVAILABLE_UNKNOWN, 
 PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */
  
  /* .. followed by some implementation specific data */
  };

I think someone already mentioned this doesn't need to be a doxygen
comment.

-- Arun

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

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

2011-10-20 Thread David Henningsson


Thanks for the review.

On 10/20/2011 10:25 AM, Arun Raghavan wrote:

On Wed, 2011-10-12 at 12:40 +0200, David Henningsson wrote:

Note: There is still no notification when status availability changes.

Signed-off-by: David Henningssondavid.hennings...@canonical.com
---

[...]

diff --git a/PROTOCOL b/PROTOCOL
index 8c69190..b8b61e4 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -278,6 +278,13 @@ New field in PA_COMMAND_UNDERFLOW:

  int64_t index

+## v24, implemented by= 2.0
+
+New field in all commands that send/receive port introspection data
+(PA_COMMAND_GET_(SOURCE|SINK)_INFO, PA_COMMAND_GET_(SOURCE|SINK)_INFO_LIST]):
+
+uint32_t available
+


Is there a reason for this to be larger than uint8_t?


Not at this point, but diverging from Ubuntu 11.10's implementation 
would not resolve the protocol skew.



   If you just changed the protocol, read this
  ## module-tunnel depends on the sink/source/sink-input/source-input protocol
  ## internals, so if you changed these, you might have broken module-tunnel.


Does module-tunnel need to care about any of this?


Yes, did you miss that part of the patch?


[...]

[diff --git a/src/pulse/def.h b/src/pulse/def.h
index f43e864..8a74fad 100644
--- a/src/pulse/def.h
+++ b/src/pulse/def.h
@@ -967,6 +967,21 @@ typedef void (*pa_free_cb_t)(void *p);
   * playback, \since 1.0 */
  #define PA_STREAM_EVENT_FORMAT_LOST format-lost

+/** Port availability / jack detection status
+ * \since 2.0 */
+typedef enum pa_port_available {
+PA_PORT_AVAILABLE_UNKNOWN = 0, /**  This port does not support jack 
detection \since 2.0 */
+PA_PORT_AVAILABLE_NO = 1,  /**  This port is not available, likely 
because the jack is not plugged in. \since 2.0 */
+PA_PORT_AVAILABLE_YES = 2, /**  This port is available, likely 
because the jack is plugged in. \since 2.0 */
+} pa_port_available_t;
+
+/** \cond fulldocs */
+#define PA_PORT_AVAILABLE_UNKNOWN PA_PORT_AVAILABLE_UNKNOWN
+#define PA_PORT_AVAILABLE_NO PA_PORT_AVAILABLE_NO
+#define PA_PORT_AVAILABLE_YES PA_PORT_AVAILABLE_YES


I'd drop the likely because since that's going to depend on other bits
of implementation (for example a jack maybe unavailable on the current
profile


The port available status is independent from whether a profile is 
active or not, and also, a port can belong to several profiles (in 
patches soon to come).



and your comment will only be true if there's a policy module to
switch profiles on jack insertion).


No, it will be true if there is a port implementation that sets jack 
availability status.





diff --git a/src/pulse/introspect.h b/src/pulse/introspect.h
index 1d77d45..7732736 100644
--- a/src/pulse/introspect.h
+++ b/src/pulse/introspect.h
@@ -202,6 +202,7 @@ typedef struct pa_sink_port_info {
  const char *name;   /**  Name of this port */
  const char *description;/**  Description of this port */
  uint32_t priority;  /**  The higher this value is the 
more useful this port is as a default */
+pa_port_available_t available;  /**  PA_PORT_AVAILABLE_UNKNOWN, 
PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */
  } pa_sink_port_info;

  /** Stores information about sinks. Please note that this structure
@@ -281,6 +282,7 @@ typedef struct pa_source_port_info {
  const char *name;   /**  Name of this port */
  const char *description;/**  Description of this port */
  uint32_t priority;  /**  The higher this value is the 
more useful this port is as a default */
+pa_port_available_t available;  /**  PA_PORT_AVAILABLE_UNKNOWN, 
PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */
  } pa_source_port_info;


I think the docs already link to the enum type, so the long comment
might be replaced by Whether the port is available or not or something
similar.


Ok, want me to resend with the comment changed?

Also, for the bool vs int thing, I think we all agree on that bools are 
okay in this context.




[...]

diff --git a/src/pulsecore/sink.h b/src/pulsecore/sink.h
index 7f639e2..39ca117 100644
--- a/src/pulsecore/sink.h
+++ b/src/pulsecore/sink.h
@@ -60,6 +60,7 @@ struct pa_device_port {
  char *description;

  unsigned priority;
+pa_port_available_t available; /**  PA_PORT_AVAILABLE_UNKNOWN, 
PA_PORT_AVAILABLE_NO or PA_PORT_AVAILABLE_YES \since 2.0 */

  /* .. followed by some implementation specific data */
  };


I think someone already mentioned this doesn't need to be a doxygen
comment.


This is already fixed in latest posted version of patch (which, for 
reference, is here 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-October/011833.html 
)



--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

2011-10-20 Thread Colin Guthrie

'Twas brillig, and Wang Xingchao at 20/10/11 08:51 did gyre and gimble:
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-client-conf.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-fork-detect.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-xmalloc.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-proplist.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-utf8.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-channelmap.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-sample.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-util.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-timeval.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-rtclock.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-authkey.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-conf-parser.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-error.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-rtclock.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-core-util.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-dynarray.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-flist.lo
   CC libpulsecommon_UNKNOWN.UNKNOWN_la-hashmap.lo
 make[3]: *** No rule to make target `pulse/i18n.c', needed by
 `libpulsecommon_UNKNOWN.UNKNOWN_la-i18n.lo'.  Stop.

I've a funny feeling that this is caused by an old checkout/clone
This file was moved a long time ago, is it possible you've just not done
a make distclean for a while or were working of a 0.9.x branch previously?

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

2011-10-20 Thread Colin Guthrie

'Twas brillig, and Tanu Kaskinen at 20/10/11 07:21 did gyre and gimble:
 On Wed, 2011-10-19 at 19:56 -0400, Chris wrote:
 (That exclamation mark means that this definition will override the
 older definition for default if it happens to have been defined
 already in some other configuration file). That alsa device will use
 whatever sink Pulseaudio thinks is best. For making alsa devices for the
 null sink and its monitor, this should work:
 
 pcm.vac {
 type pulse
 device vac
 }
 
 pcm.vacmonitor {
 type pulse
 device vac.monitor
 }
 

You can also provide a hint which some alsa clients will use:


pcm.vac {
type pulse
device vac
hint {
show on
description My Nice VAC
}
}

aplay -L
vac
My Nice VAC



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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Pulse and audio settings

2011-10-20 Thread Colin Guthrie

'Twas brillig, and Robert Orzanna at 20/10/11 07:05 did gyre and gimble:
 I don't see any way how to adjust PCM which by default is set to 100
 by pulseaudio. Hence, I must use alsamixer to reduce the distortions
 caused by the high PCM.

Oops, I didn't see this bit before due to HTML formatting :( (please try
to use plain text if you can).

This is a bug in ALSA. If high PCM values result in distortions then
ALSA is either misreporting the dB values for the PCM channel or
something else is going on. It is correct that PA uses PCM in it's mixer
pipeline and this will not be changed. Any bugs need to be fixed
properly where they occur, not papered over. You should report this via
alsa-devel list.

You can tell PA not to use PCM mixer but it requires that you load alsa
module-alsa-sink manually and pass in the control= param (see the
modules page on the wiki) which can get in the way of hotplug (you'd
have to set your card to an input only profile so that you can load the
sink manually in default.pa to ensure hotplug still worked).

Hope that helps

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Pulse and audio settings

2011-10-20 Thread Colin Guthrie

'Twas brillig, and Robert Orzanna at 20/10/11 07:05 did gyre and gimble:
 Of course I can run alsactl restore after pulseaudio had completely
 started. But this is only a workaround since it is obviously not
 indented to overwrite pulse settings.

I think you misunderstand. You should run this *before* PA starts.

You were originally concerned about saving/restoring settings that PA
does not alter or touch at all. This is exactly what alsactl
store/restre handles.

We don't touch any alsa settings that we specifically do not want to set
in PA.

If there is a specific problem in that PA *is* touching, but you reckon
it shouldn't, then please clarify this with some examples (e.g.
amixer/alsa-info.sh output and specific element names).

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

2011-10-20 Thread Wang Xingchao

 I've a funny feeling that this is caused by an old checkout/clone
 This file was moved a long time ago, is it possible you've just not done
 a make distclean for a while or were working of a 0.9.x branch previously?

hey Col,

i checkout remote branch remotes/origin/orcify after clone from :
https://github.com/mkbosmans/pulseaudio.git

Anyway, i've merged the svolume-test to latest git and under test now.

thanks
--xingchao


 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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[pulseaudio-discuss] [PATCH 1/2] sbc: overflow bugfix and audio decoding quality improvement

2011-10-20 Thread Luiz Augusto von Dentz

From: Siarhei Siamashka siarhei.siamas...@nokia.com

The (((audio_sample  1) | 1)  frame-scale_factor[ch][sb])
part of expression
frame-sb_sample[blk][ch][sb] =
(((audio_sample  1) | 1)  frame-scale_factor[ch][sb]) /
levels[ch][sb] - (1  frame-scale_factor[ch][sb])
in sbc_unpack_frame function can sometimes overflow 32-bit signed int.
This problem can be reproduced by first using bitpool 128 and encoding
some random noise data, and then feeding it to sbc decoder. The obvious
thing to do would be to change audio_sample variable type to uint32_t.

However the problem is a little bit more complicated. According
to the section 12.6.2 Scale Factors of A2DP spec:
scalefactor[ch][sb] = pow(2.0, (scale_factor[ch][sb] + 1))

And according to 12.6.4 Reconstruction of the Subband Samples:
sb_sample[blk][ch][sb] = scalefactor[ch][sb] *
((audio_sample[blk][ch][sb]*2.0+1.0) / levels[ch][sb]-1.0);

Hence the current code for calculating sb_sample[blk][ch][sb] is
not quite correct, because it loses one least significant bit of
sample data and passes twice smaller sample values to the synthesis
filter (the filter also deviates from the spec to compensate this).
This all has quite a noticeable impact on audio quality. Moreover,
it makes sense to keep a few extra bits of precision here in order
to minimize rounding errors. So the proposed patch introduces a new
SBCDEC_FIXED_EXTRA_BITS constant and uses uint64_t data type
for intermediate calculations in order to safeguard against
overflows. This patch intentionally addresses only the quality
issue, but performance can be also improved later (like replacing
division with multiplication by reciprocal).

Test for the difference of sbc encoding/decoding roundtrip vs.
the original audio file for joint stereo, bitpool 128, 8 subbands
and http://media.xiph.org/sintel/sintel-master-st.flac sample
demonstrates some quality improvement:

=== before ===
--- comparing original / sbc_encoder.exe + sbcdec ---
stddev:4.64 PSNR: 82.97 bytes:170495708/170496000
=== after ===
--- comparing original / sbc_encoder.exe + sbcdec ---
stddev:1.95 PSNR: 90.50 bytes:170495708/170496000
---
 src/modules/bluetooth/sbc/sbc.c|   11 +++
 src/modules/bluetooth/sbc/sbc_tables.h |6 --
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/modules/bluetooth/sbc/sbc.c b/src/modules/bluetooth/sbc/sbc.c
index 77fcc5d..ad391bd 100644
--- a/src/modules/bluetooth/sbc/sbc.c
+++ b/src/modules/bluetooth/sbc/sbc.c
@@ -383,7 +383,7 @@ static int sbc_unpack_frame(const uint8_t *data, struct 
sbc_frame *frame,
int crc_pos = 0;
int32_t temp;
 
-   int audio_sample;
+   uint32_t audio_sample;
int ch, sb, blk, bit;   /* channel, subband, block and bit standard
   counters */
int bits[2][8]; /* bits distribution */
@@ -494,6 +494,9 @@ static int sbc_unpack_frame(const uint8_t *data, struct 
sbc_frame *frame,
for (ch = 0; ch  frame-channels; ch++) {
for (sb = 0; sb  frame-subbands; sb++) {
if (levels[ch][sb]  0) {
+   uint32_t shift =
+   frame-scale_factor[ch][sb] +
+   1 + SBCDEC_FIXED_EXTRA_BITS;
audio_sample = 0;
for (bit = 0; bit  bits[ch][sb]; 
bit++) {
if (consumed  len * 8)
@@ -505,9 +508,9 @@ static int sbc_unpack_frame(const uint8_t *data, struct 
sbc_frame *frame,
consumed++;
}
 
-   frame-sb_sample[blk][ch][sb] =
-   (((audio_sample  1) | 1)  
frame-scale_factor[ch][sb]) /
-   levels[ch][sb] - (1  
frame-scale_factor[ch][sb]);
+   frame-sb_sample[blk][ch][sb] = 
(int32_t)
+   (uint64_t) audio_sample  
1) | 1)  shift) /
+   levels[ch][sb]) - (1  shift);
} else
frame-sb_sample[blk][ch][sb] = 0;
}
diff --git a/src/modules/bluetooth/sbc/sbc_tables.h 
b/src/modules/bluetooth/sbc/sbc_tables.h
index 28c0d54..25e24e6 100644
--- a/src/modules/bluetooth/sbc/sbc_tables.h
+++ b/src/modules/bluetooth/sbc/sbc_tables.h
@@ -40,11 +40,13 @@ static const int sbc_offset8[4][8] = {
{ -4, 0, 0, 0, 0, 0, 1, 2 }
 };
 
+/* extra bits of precision for the synthesis filter input data */
+#define SBCDEC_FIXED_EXTRA_BITS 2
 
 #define SS4(val) ASR(val, SCALE_SPROTO4_TBL)
 #define SS8(val) ASR(val,

[pulseaudio-discuss] [PATCH 2/2] sbc: Reduce for-loop induced indentation in sbc_unpack_frame

2011-10-20 Thread Luiz Augusto von Dentz

From: Johan Hedberg johan.hedb...@intel.com

---
 src/modules/bluetooth/sbc/sbc.c |   36 
 1 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/src/modules/bluetooth/sbc/sbc.c b/src/modules/bluetooth/sbc/sbc.c
index ad391bd..c5015ab 100644
--- a/src/modules/bluetooth/sbc/sbc.c
+++ b/src/modules/bluetooth/sbc/sbc.c
@@ -493,26 +493,30 @@ static int sbc_unpack_frame(const uint8_t *data, struct 
sbc_frame *frame,
for (blk = 0; blk  frame-blocks; blk++) {
for (ch = 0; ch  frame-channels; ch++) {
for (sb = 0; sb  frame-subbands; sb++) {
-   if (levels[ch][sb]  0) {
-   uint32_t shift =
-   frame-scale_factor[ch][sb] +
+   uint32_t shift;
+
+   if (levels[ch][sb] == 0) {
+   frame-sb_sample[blk][ch][sb] = 0;
+   continue;
+   }
+
+   shift = frame-scale_factor[ch][sb] +
1 + SBCDEC_FIXED_EXTRA_BITS;
-   audio_sample = 0;
-   for (bit = 0; bit  bits[ch][sb]; 
bit++) {
-   if (consumed  len * 8)
-   return -1;
 
-   if ((data[consumed  3]  (7 
- (consumed  0x7)))  0x01)
-   audio_sample |= 1  
(bits[ch][sb] - bit - 1);
+   audio_sample = 0;
+   for (bit = 0; bit  bits[ch][sb]; bit++) {
+   if (consumed  len * 8)
+   return -1;
 
-   consumed++;
-   }
+   if ((data[consumed  3]  (7 - 
(consumed  0x7)))  0x01)
+   audio_sample |= 1  
(bits[ch][sb] - bit - 1);
 
-   frame-sb_sample[blk][ch][sb] = 
(int32_t)
-   (uint64_t) audio_sample  
1) | 1)  shift) /
-   levels[ch][sb]) - (1  shift);
-   } else
-   frame-sb_sample[blk][ch][sb] = 0;
+   consumed++;
+   }
+
+   frame-sb_sample[blk][ch][sb] = (int32_t)
+   (uint64_t) audio_sample  1) | 1) 
 shift) /
+   levels[ch][sb]) - (1  shift);
}
}
}
-- 
1.7.6.4

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

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 1.1

2011-10-20 Thread Colin Guthrie

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

I promised more regular releases so more regular releases you will have!

This is a relatively small bug fix for 1.0 but it does address a few
issues, the highlights of which are:

 * Reintroduce a 3 point version string in various API calls. It seems
some apps (i.e Skype) and build systems (i.e. KDE CMake scripts)
parsed this data and assumed it would always have three numerical
parts. While this is bad practice generally and should be fixed in
said apps, we don't really have any problem with providing a 3 point
version in internal APIs so to prevent problems, we've just tacked a
.0 on the end.
 * Fix some linking errors that accidentally linked libpulse to
libpulsecore which could under some circumstance downgrade libpulse
to GPL (rather than LGPL) which could in turn cause problems with
non-GPL compatible apps which link to libpulse.
 * Fix a problem where starting PA without X11 would fail due to dbus
problems (note: some bugs were found trying to initialise PA X11
modules after subsequently logging into X11 when PA was started on the
console, but this is a regression in 1.0 and I didn't want to delay
1.1 for this corner case alone. It should be fixed in the next update).
 * Some Solaris fixes now that they are migrating to PA (probably a
few more issues still, but these will likely land in 2.0)

http://freedesktop.org/software/pulseaudio/releases/pulseaudio-1.1.tar.xz
MD5:  17d21df798cee407b769c6355fae397a
SHA1: 5ff451389951f79949a461b95168558cc4120e73

Special thanks to Arun for doing the bulk of the fixes in this round
and for most of the management side of things too! Thanks always to
everyone involved.

Here is the complete shortlog:

Arun Raghavan (12):
  extended: Fix doxygen comment style typos
  sink,source: Avoid unnecessary call to pa_rtclock_now()
  alsa: Give compressed formats preference over PCM
  alsa: Better error handling in mixer rtpoll callback
  echo-cancel: Fail if loaded between a sink and its monitor
  alsa: Make mixer error handling more robust still
  echo-cancel: Don't crash if adjust_time = 0
  echo-cancel: Close debug files on module unload
  filter-apply: Move sink/source unlink callbacks before m-s-r
  build-sys: Drop libsamplerate from pulsecommon deps
  native: Fix Solaris build
  solaris: Use real_volume for set/get volume

Colin Guthrie (5):
  libpulse: Always return a three part version number in API calls.
  build-sys: Provide a simple CMake Config setup (similar to
pkgconfig)
  Update LICENSE.
  conf: Use .nofail when loading module-jackdbus-detect
  build-sys: bump soname

Daniel Mack (2):
  osx: don't build the once-test binary on OS X
  osx: module_bonjour_publish needs to be linked against
libprotocol-native.la

David Henningsson (3):
  module-jackdbus-detect: Avoid double-free of modargs
  source-output: Do not use unset channel map in pa_source_output_new
  Fix deferred volume not being applied if sink is closed

Maarten Bosmans (3):
  Make pulse build with clang again
  doc: Add some more doxygen tags to existing comments
  tests: Fix calculation of memblock size in resampler-test

Sudarshan Bisht (1):
  null-sink: Set latency range at the time of initialization of
module.

Tanu Kaskinen (2):
  sink: Move updating the requested latency after the rewind
request when finishing a stream move.
  daemon: Don't treat it as a fatal error if we can't connect to
the session bus



- -- 

Colin Guthrie
colin(at)mageia.org
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6gI4YACgkQCoRSYD8tmNgBiACfS8Zez1lPwQX88ST4YvJcxj7I
SyMAn3qFiimSiI7yN7rEQXOAtvOySJ2J
=HWKT
-END PGP SIGNATURE-
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

2011-10-20 Thread Chris

Thanks guys, this clears things up for me.

On Thu, Oct 20, 2011 at 5:17 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Tanu Kaskinen at 20/10/11 07:21 did gyre and gimble:
 On Wed, 2011-10-19 at 19:56 -0400, Chris wrote:
 (That exclamation mark means that this definition will override the
 older definition for default if it happens to have been defined
 already in some other configuration file). That alsa device will use
 whatever sink Pulseaudio thinks is best. For making alsa devices for the
 null sink and its monitor, this should work:

 pcm.vac {
     type pulse
     device vac
 }

 pcm.vacmonitor {
     type pulse
     device vac.monitor
 }


 You can also provide a hint which some alsa clients will use:


 pcm.vac {
    type pulse
    device vac
    hint {
        show on
        description My Nice VAC
    }
 }

 aplay -L
 vac
    My Nice VAC
 


 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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss




-- 
73      de     Chris       KC2RGW
---
˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Pulse and audio settings

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

Re: [pulseaudio-discuss] [PATCH] alsa-card: Handle the profile modarg.

Re: [pulseaudio-discuss] [PATCH] Remove time-smoother and shm from libpulsecore

Re: [pulseaudio-discuss] [PATCH] fix two warnings in utils/padsp.c

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

Re: [pulseaudio-discuss] [PATCH] Introduce available concept for ports, and communicate that to clients. Bump protocol version to 24.

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

Re: [pulseaudio-discuss] Pulse and audio settings

Re: [pulseaudio-discuss] Pulse and audio settings

Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation

[pulseaudio-discuss] [PATCH 1/2] sbc: overflow bugfix and audio decoding quality improvement

[pulseaudio-discuss] [PATCH 2/2] sbc: Reduce for-loop induced indentation in sbc_unpack_frame

[pulseaudio-discuss] [ANNOUNCE] PulseAudio 1.1

Re: [pulseaudio-discuss] Getting a null sink to show up as an ALSA device.

20 matches

Site Navigation

Mail list logo

Footer information