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 :
> 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 :
> 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 :
> On Tue, 2011-10-18 at 12:10 +0200, Maarten Bosmans wrote:
>> > 2011/10/18 Wang Xingchao :
>> >> 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 :
> 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 
>> ---
>
> 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 
> ---
[...]
> 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 Henningsson
---

[...]

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

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

2011-10-20 Thread Wang Xingchao 
Hey Maarten,

with your test tool svolume-test, i get some new test results shows
the patch has a positive performance improvement. please note i made
some little change in svolume-test to disable "testing correctness"
part, this save some time, the goal is to find out performance
difference with fixed volume.

i made three times test, one with patch, two without(make sure system
stable during the test).

i paste piece of data here, details are in attached log.

Here's the stastics for format s16, channel 1~4, fixed volume, with patch:

checking s16le - 1 channels - fixed volume
ref:  70.4 ms   (min =  70.4, max =  71.4, stddev =  0.2)
asm:   2.9 ms   (min =   2.9, max =   3.0, stddev =  0.0)

checking s16le - 2 channels - fixed volume
ref:  85.1 ms   (min =  85.1, max =  85.7, stddev =  0.1)
asm:   5.9 ms   (min =   5.9, max =   6.2, stddev =  0.1)

checking s16le - 3 channels - fixed volume
ref: 127.8 ms   (min = 127.7, max = 128.6, stddev =  0.2)
asm:   8.9 ms   (min =   8.9, max =   8.9, stddev =  0.0)

checking s16le - 4 channels - fixed volume
ref: 170.2 ms   (min = 170.1, max = 170.9, stddev =  0.2)
asm:  11.8 ms   (min =  11.8, max =  11.9, stddev =  0.0)
=

while same format/channel/fixed volume without patch:
=
checking s16le - 1 channels - fixed volume
ref:  70.4 ms   (min =  70.4, max =  70.8, stddev =  0.1)
asm:   2.9 ms   (min =   2.9, max =   3.0, stddev =  0.0)

checking s16le - 2 channels - fixed volume
ref: 141.0 ms   (min = 140.9, max = 142.4, stddev =  0.3)
asm:   6.0 ms   (min =   6.0, max =   6.1, stddev =  0.0)

checking s16le - 3 channels - fixed volume
ref: 213.7 ms   (min = 213.5, max = 214.5, stddev =  0.2)
asm:   9.0 ms   (min =   8.9, max =   9.3, stddev =  0.1)

checking s16le - 4 channels - fixed volume
ref: 286.5 ms   (min = 285.5, max = 301.0, stddev =  2.6)
asm:  12.0 ms   (min =  12.0, max =  12.3, stddev =  0.1)
==

please help review the results.

--xingchao


screenlog.1
Description: Binary data
___
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 

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

[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 

---
 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] [PATCH] Introduce "available" concept for ports, and communicate that to clients. Bump protocol version to 24.

2011-10-20 Thread David Henningsson 
Note: There is still no notification when status availability changes.

Signed-off-by: David Henningsson 
---
 PROTOCOL|   10 
 configure.ac|2 +-
 src/modules/module-tunnel.c |   91 +--
 src/pulse/def.h |   15 ++
 src/pulse/introspect.c  |   16 +++
 src/pulse/introspect.h  |2 +
 src/pulsecore/protocol-native.c |4 ++
 src/pulsecore/sink.h|1 +
 8 files changed, 88 insertions(+), 53 deletions(-)

diff --git a/PROTOCOL b/PROTOCOL
index 8c69190..8b2f81f 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -278,6 +278,16 @@ 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)_OUTPUT_INFO,
+PA_COMMAND_GET_(SOURCE|SINK)_OUTPUT_INFO_LIST):
+
+uint32_t available
+
+The field is added once for every port.
+
  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.
diff --git a/configure.ac b/configure.ac
index 0bf40a8..d57dbc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,7 +36,7 @@ AC_SUBST(PA_MINOR, pa_minor)
 AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
 
 AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 23)
+AC_SUBST(PA_PROTOCOL_VERSION, 24)
 
 # The stable ABI for client applications, for the version info x:y:z
 # always will hold y=z
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index faee995..7053368 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tunnel.c
@@ -996,6 +996,41 @@ fail:
 pa_module_unload_request(u->module, TRUE);
 }
 
+static int read_ports(struct userdata *u, pa_tagstruct *t)
+{
+if (u->version >= 16) {
+uint32_t n_ports;
+const char *s;
+
+if (pa_tagstruct_getu32(t, &n_ports)) {
+pa_log("Parse failure");
+return FALSE;
+}
+
+for (uint32_t j = 0; j < n_ports; j++) {
+uint32_t priority;
+
+if (pa_tagstruct_gets(t, &s) < 0 || /* name */
+pa_tagstruct_gets(t, &s) < 0 || /* description */
+pa_tagstruct_getu32(t, &priority) < 0) {
+
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+if (u->version >= 24 && pa_tagstruct_getu32(t, &priority) < 0) { 
/* available */
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+}
+
+if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+}
+return 0;
+}
+
 #ifdef TUNNEL_SINK
 
 /* Called from main context */
@@ -1066,32 +1101,8 @@ static void sink_info_cb(pa_pdispatch *pd, uint32_t 
command,  uint32_t tag, pa_t
 }
 }
 
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (read_ports(u, t) < 0)
+goto fail;
 
 if (u->version >= 21) {
 uint8_t n_formats;
@@ -1318,32 +1329,8 @@ static void source_info_cb(pa_pdispatch *pd, uint32_t 
command,  uint32_t tag, pa
 }
 }
 
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (read_ports(u, t) < 0)
+goto fail;
 
 if (!pa_tagstruct_eof(t)) {
 pa_log("Packet too long");
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 (*p

[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

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

2011-10-20 Thread David Henningsson 
Note: There is still no notification when status availability changes.

Signed-off-by: David Henningsson 
---
 PROTOCOL|   10 
 configure.ac|2 +-
 src/modules/module-tunnel.c |   91 +--
 src/pulse/def.h |   15 ++
 src/pulse/introspect.c  |   16 +++
 src/pulse/introspect.h  |2 +
 src/pulsecore/protocol-native.c |4 ++
 src/pulsecore/sink.h|1 +
 8 files changed, 88 insertions(+), 53 deletions(-)

diff --git a/PROTOCOL b/PROTOCOL
index 8c69190..8b2f81f 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -278,6 +278,16 @@ 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)_OUTPUT_INFO,
+PA_COMMAND_GET_(SOURCE|SINK)_OUTPUT_INFO_LIST):
+
+uint32_t available
+
+The field is added once for every port.
+
  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.
diff --git a/configure.ac b/configure.ac
index 0bf40a8..d57dbc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,7 +36,7 @@ AC_SUBST(PA_MINOR, pa_minor)
 AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
 
 AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 23)
+AC_SUBST(PA_PROTOCOL_VERSION, 24)
 
 # The stable ABI for client applications, for the version info x:y:z
 # always will hold y=z
diff --git a/src/modules/module-tunnel.c b/src/modules/module-tunnel.c
index faee995..61ec35d 100644
--- a/src/modules/module-tunnel.c
+++ b/src/modules/module-tunnel.c
@@ -996,6 +996,41 @@ fail:
 pa_module_unload_request(u->module, TRUE);
 }
 
+static int read_ports(struct userdata *u, pa_tagstruct *t)
+{
+if (u->version >= 16) {
+uint32_t n_ports;
+const char *s;
+
+if (pa_tagstruct_getu32(t, &n_ports)) {
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+
+for (uint32_t j = 0; j < n_ports; j++) {
+uint32_t priority;
+
+if (pa_tagstruct_gets(t, &s) < 0 || /* name */
+pa_tagstruct_gets(t, &s) < 0 || /* description */
+pa_tagstruct_getu32(t, &priority) < 0) {
+
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+if (u->version >= 24 && pa_tagstruct_getu32(t, &priority) < 0) { 
/* available */
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+}
+
+if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
+pa_log("Parse failure");
+return -PA_ERR_PROTOCOL;
+}
+}
+return 0;
+}
+
 #ifdef TUNNEL_SINK
 
 /* Called from main context */
@@ -1066,32 +1101,8 @@ static void sink_info_cb(pa_pdispatch *pd, uint32_t 
command,  uint32_t tag, pa_t
 }
 }
 
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (read_ports(u, t) < 0)
+goto fail;
 
 if (u->version >= 21) {
 uint8_t n_formats;
@@ -1318,32 +1329,8 @@ static void source_info_cb(pa_pdispatch *pd, uint32_t 
command,  uint32_t tag, pa
 }
 }
 
-if (u->version >= 16) {
-uint32_t n_ports;
-const char *s;
-
-if (pa_tagstruct_getu32(t, &n_ports)) {
-pa_log("Parse failure");
-goto fail;
-}
-
-for (uint32_t j = 0; j < n_ports; j++) {
-uint32_t priority;
-
-if (pa_tagstruct_gets(t, &s) < 0 || /* name */
-pa_tagstruct_gets(t, &s) < 0 || /* description */
-pa_tagstruct_getu32(t, &priority) < 0) {
-
-pa_log("Parse failure");
-goto fail;
-}
-}
-
-if (pa_tagstruct_gets(t, &s) < 0) { /* active port */
-pa_log("Parse failure");
-goto fail;
-}
-}
+if (read_ports(u, t) < 0)
+goto fail;
 
 if (!pa_tagstruct_eof(t)) {
 pa_log("Packet too long");
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 @@ typed

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