Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
Can you elaborate on what you had in mind regarding UIs?
As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink. Of course, pactl/pacmd
would expose this data too. Other than informative purposes, it would
also make debugging simpler (Hey, my BT headset isn't playing MP3s
automatically .. Can you check if it's actually supported using these
simple steps?)
Yes, the supported formats should be provided in the sink introspection
data. This isn't necessarily relevant when creating streams, though.
Does the assumption, that all sinks support PCM streams, cause some
actual consequences in terms of API? I can't immediately see any
consequences - it seems like an implementation detail that can be
changed later. (I'd like to reserve the possibility to have
passthrough-only sinks in the future, just in case.)
Fair enough. The only niggling API change would be adding a
PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
each PCM format).
I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
legacy thing for clients that aren't interested in anything else than
PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding
type can be provided with a new enumeration with PA_ENCODING_PCM,
PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for
representing the format set, can contain information saying that
everything is supported.
I didn't get the last bit about what you'd add to the proplist. The
separate enum would work well for the format_info struct, but would you
also suggest extending the API to use the encoding type while setting
up/connecting streams?
I would suggest that the sinks and the clients use the same presentation
for describing the supported formats. It may be a proplist or something
else. In a purely proplist-based solution there may be no need to extend
the stream creation API. However, a purely proplist-based solution would
look hacky to me, but that's a matter of taste.
If I had to decide the format set representation now, I might do it as
follows:
typedef enum pa_encoding {
PA_ENCODING_PCM,
PA_ENCODING_MP3,
...
}
typedef struct pa_format_desc {
pa_encoding_t encoding;
pa_proplist *params; /* string - string: parameter name
* to parameter value. The parameter
* value has syntax for representing
* also lists and ranges. Missing
* parameter means that anything is
* allowed, unknown parameters are
* ignored. */
} pa_format_desc;
Uh, that ended up pretty identical to your pa_format_info proposal, even
though I didn't mean to :) I tried to replace the proplist with a
solution that doesn't require any string parsing, but that ended up very
complicated.
I'm proposing that a new function is added for creating streams that
takes a list of pa_format_desc structs (or maybe pa_format_info is a
better name) instead of sample spec and channel map.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. Yeah, I agree with this statement. It just feels cleaner (my comment about the format being used in the routing would still be an issue here but I agree that it was probably an extreme example that wouldn't really be needed in practice anyway). If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). The client can also choose not to specify any formats. In that case the routing logic can't use the format as input for decisions, but currently there's no such routing logic anyway. After routing is done, the stream enters to a new state, PA_STREAM_ROUTED. In this state the client has to query the set of formats that the sink supports, and decide the final format. When the client sets the format, the stream changes state to PA_STREAM_READY. Hmm, that could work... not really though through the implications of adding a new state here, but I don't think it would cause major headaches downstream. 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] [RFC] Passthrough support
On Thu, 2011-02-17 at 10:26 +0200, Tanu Kaskinen wrote:
On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
Can you elaborate on what you had in mind regarding UIs?
As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink. Of course, pactl/pacmd
would expose this data too. Other than informative purposes, it would
also make debugging simpler (Hey, my BT headset isn't playing MP3s
automatically .. Can you check if it's actually supported using these
simple steps?)
Yes, the supported formats should be provided in the sink introspection
data. This isn't necessarily relevant when creating streams, though.
Ah, right. I was squashing things that aren't really related.
[...]
I would suggest that the sinks and the clients use the same presentation
for describing the supported formats. It may be a proplist or something
else. In a purely proplist-based solution there may be no need to extend
the stream creation API. However, a purely proplist-based solution would
look hacky to me, but that's a matter of taste.
If I had to decide the format set representation now, I might do it as
follows:
typedef enum pa_encoding {
PA_ENCODING_PCM,
PA_ENCODING_MP3,
...
}
typedef struct pa_format_desc {
pa_encoding_t encoding;
pa_proplist *params; /* string - string: parameter name
* to parameter value. The parameter
* value has syntax for representing
* also lists and ranges. Missing
* parameter means that anything is
* allowed, unknown parameters are
* ignored. */
} pa_format_desc;
Uh, that ended up pretty identical to your pa_format_info proposal, even
though I didn't mean to :) I tried to replace the proplist with a
solution that doesn't require any string parsing, but that ended up very
complicated.
Good to see we converged on the same structure. :)
bikeshed Building on the pa_sample_spec naming, pa_stream_spec,
perhaps? /bikeshed
I'm proposing that a new function is added for creating streams that
takes a list of pa_format_desc structs (or maybe pa_format_info is a
better name) instead of sample spec and channel map.
Rethinking this, I'm starting to agree with you and Pierre on this. For
the PA_ENCODING_PCM, the proplist would basically just encode the same
data that's in pa_sample_spec. For other formats, we can add the data we
need.
I'm researching you other proposal and will update the proposal on the
wiki with both these in a while.
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] Implement the volume sharing feature.
DON'T COMMIT. This is just a request for comments. Testing this patch
isn't done properly yet.
When we have a filter sink that does some processing, currently the
benefits of the flat volume feature are not really available. That's
because if you have a music player that is connected to the filter sink,
the hardware sink doesn't have any idea of the music player's stream
volume.
This problem is solved by this volume sharing feature. The volume
sharing feature works so that the filter sinks that want to avoid the
previously described problem declare that they don't want to have
independent volume, but they follow the master sink volume instead.
The PA_SINK_SHARE_VOLUME_WITH_MASTER sink flag is used for that
declaration. Then the volume logic is changed so that the hardware
sink calculates its real volume using also the streams connected to the
filter sink in addition to the streams that are connected directly to
the hardware sink. Basically we're trying to create an illusion that
from volume point of view all streams are connected directly to the
hardware sink.
For that illusion to work, the volumes of the filter sinks and their
virtual streams have to be managed carefully according to a set of
rules:
If a filter sink follows the hardware sink volume, then the filter sink's
* reference_volume always equals the hw sink's reference_volume
* real_volume always equals the hw sink's real_volume
* soft_volume is always 0dB (ie. no soft volume)
If a filter sink doesn't follow the hardware sink volume, then the filter
sink's
* reference_volume can be whatever (completely independent from the hw sink)
* real_volume always equals reference_volume
* soft_volume always equals real_volume (and reference_volume)
If a filter sink follows the hardware sink volume, and the hardware sink
supports flat volume, then the filter sink's virtual stream's
* volume always equals the hw sink's real_volume
* reference_ratio is calculated normally from the stream volume and the hw
sink's reference_volume
* real_ratio always equals 0dB (follows from the first point)
* soft_volume always equals volume_factor (follows from the previous point)
If a filter sink follows the hardware sink volume, and the hardware sink
doesn't support flat volume, then the filter sink's virtual stream's
* volume is always 0dB
* reference_ratio is always 0dB
* real_ratio is always 0dB
* soft_volume always equals volume_factor
If a filter sink doesn't follow the hardware sink volume, then the filter
sink's virtual stream is handled as a regular stream.
Since the volumes of the virtual streams are controlled by a set of rules,
the user is not allowed to change the virtual streams' volumes. It would
probably also make sense to forbid changing the filter sinks' volume, but
that's not strictly necessary, and currently changing a filter sink's volume
changes actually the hardware sink's volume, and from there it propagates to
all filter sinks (funny effects are expected when adjusting a single
channel in cases where all sinks don't have the same channel maps).
---
src/pulse/def.h | 11 +
src/pulsecore/protocol-native.c |2 +-
src/pulsecore/sink-input.c | 201 +--
src/pulsecore/sink.c| 540 +++
src/pulsecore/sink.h|4 +
5 files changed, 575 insertions(+), 183 deletions(-)
diff --git a/src/pulse/def.h b/src/pulse/def.h
index 4a8da13..f6de7b3 100644
--- a/src/pulse/def.h
+++ b/src/pulse/def.h
@@ -749,6 +749,16 @@ typedef enum pa_sink_flags {
/** The HW volume changes are syncronized with SW volume.
* \since 1.0 */
+/** \cond fulldocs */
+/* PRIVATE: Server-side values -- do not try to use these at client-side.
+ * The server will filter out these flags anyway, so you should never see
+ * these flags in sinks. */
+
+PA_SINK_SHARE_VOLUME_WITH_MASTER = 0x0400U,
+/** This sink shares the volume with the master sink (used by some filter
+ * sinks). */
+/** \endcond */
+
} pa_sink_flags_t;
/** \cond fulldocs */
@@ -762,6 +772,7 @@ typedef enum pa_sink_flags {
#define PA_SINK_DYNAMIC_LATENCY PA_SINK_DYNAMIC_LATENCY
#define PA_SINK_PASSTHROUGH PA_SINK_PASSTHROUGH
#define PA_SINK_SYNC_VOLUME PA_SINK_SYNC_VOLUME
+#define PA_SINK_SHARE_VOLUME_WITH_MASTER PA_SINK_SHARE_VOLUME_WITH_MASTER
/** \endcond */
diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c
index 9257524..c812a3e 100644
--- a/src/pulsecore/protocol-native.c
+++ b/src/pulsecore/protocol-native.c
@@ -2902,7 +2902,7 @@ static void sink_fill_tagstruct(pa_native_connection *c,
pa_tagstruct *t, pa_sin
PA_TAG_STRING, sink-monitor_source ? sink-monitor_source-name :
NULL,
PA_TAG_USEC, pa_sink_get_latency(sink),
PA_TAG_STRING, sink-driver,
-PA_TAG_U32, sink-flags,
+PA_TAG_U32, sink-flags ~PA_SINK_SHARE_VOLUME_WITH_MASTER,
PA_TAG_INVALID);
if (c-version = 13) {
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi Tanu, On Thu, 2011-02-17 at 09:45 +0200, Tanu Kaskinen wrote: On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote: On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Thanks for the detailed proposal! Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. The client can also choose not to specify any formats. In that case the routing logic can't use the format as input for decisions, but currently there's no such routing logic anyway. After routing is done, the stream enters to a new state, PA_STREAM_ROUTED. In this state the client has to query the set of formats that the sink supports, and decide the final format. When the client sets the format, the stream changes state to PA_STREAM_READY. This sounds pretty clean overall, and after talking to Wim on IRC for a bit, I think we might even be able to do without the no-formats variant of the API. That said, it would be nice to have the last bit as well, so I'll keep it put it down as something to add after the basic bits are done. I've updated the wiki with this version now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. Yeah, I agree with this statement. It just feels cleaner (my comment about the format being used in the routing would still be an issue here but I agree that it was probably an extreme example that wouldn't really be needed in practice anyway). If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). I probably didn't understand this correctly, but wouldn't this only be helpful if a new sink comes in exactly between when the routing fails and when you retry? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). Aargh! An unmatched left parenthesis creates an unresolved tension that will stay with me all day! And here you put TWO unmatched parentheses, I'll be tense also tomorrow :( Well, I think I can manage. Anyway, I think this is completely up to the routing logic. It should check the compatibility before doing the routing decision in the first place, if it is somehow aware of the possibility of incompatibility. This way there's no need to go back, which sounds very complicated. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support (extending proplists)
On Wed, 2011-02-16 at 12:33 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
[...]
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
This one will probably be somewhat contentious. I was going to put this
information in the format_info structure's proplist so clients can read
and match as they please. There is one stumbling block here in that
proplists do not allow list or range types.
We can either support these by abusing the proplists a bit (for ranges
have a prop.min and prop.max, for lists have prop.num_elements,
prop.elem_0, prop.elem_1, etc.), using simple strings (the way
GstCaps are done) or add first-class list and range types. Listed in
increasing order of effort.
IMO the first is too hacky. The second is quite flexible, but
potentially too generic? The third is the most disruptive, but also most
exactly suited to what we need.
I'm leaning towards the second (string representation like (type) [min,
max] for range and (type) { val1, val2, val3 } for list). In the
current context, the type might be implicit in the key, but since this
literally becomes part of the API, I'd like to plan ahead.
Thoughts?
Random suggestion:
1. The range thing seems simple enough the prop.min and prop.max seems
like an easy enough thing to list and support (perhaps even with a
wrapper function if it saves a bit of sanity checking).
2. The lists are slightly harder, so how about we just support JSON
style syntax here for simple array storage? i.e. ['val1','val2','val\'s
beyond'] ? Again a wrapper function or two can help create/decode
these? Using a format like JSON should be pretty simple and we could
easily enough push out the whole proplist as a single JSON encoded thing
at some point in the future if needed too.
We really should decide on what we need first, I guess :)
I assume that for a given property, the data type is implicitly
understood (this is how things work now).
The other thing to worry about is whether a given property should be
expected to only be either single-valued, a range or a list. This might
not be true - for example when querying a sink, you might get the
supported sample rates as a list, but when connecting, sample rate is
single-valued (we might not use properties to set the sample rate, but
as a generic data structure, I hope you see my point).
From the API perspective, perhaps we could add an enum to represent the
type (single-valued, multi-valued, range), and then have an API to query
this (like pa_proplist_get_type(proplist, key)) that clients would use
if multiple possibilities exist. We can then have API for each type.
Implementation wise, I think it's nicer to just have one key and do some
string parsing for the range case as well.
One thing to note here is that we cannot support lists of strings since,
aiui, JSON requires that strings be enclosed in quotes and we do not
currently do this for single-valued strings. The json.org site is down,
so if I'm wrong, I blame Wikipedia. :)
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Build assembler errors on ARM OMAP3
Thanks for your help Arun. I was finally able to come back to this problem.
Here is the last lines of a make on a clean git clone showing the errors on
the beagleboard (linaro ALIP).
Adding ite before the addcs did not build, adding itt built and ran, but
unloaded alsa module.
http://pastebin.com/Lqw0rEh9
Kurt Taylor (irc krtaylor)
On 14 February 2011 08:45, Arun Raghavan arun.ragha...@collabora.co.ukwrote:
On Mon, 2011-02-07 at 12:52 -0600, Kurt Taylor wrote:
I am seeing the following when trying to build pulseaudio on an
ARM-based Beagleboard (OMAP3):
CC libpulsecore_1.0_la-svolume_arm.lo
../libtool: line 975: warning: setlocale: LC_MESSAGES: cannot change
locale (en_GB.utf8)
{standard input}: Assembler messages:
{standard input}:82: Error: thumb conditional instruction should be in
IT block -- `addcs r0,r8'
{standard input}:83: Error: thumb conditional instruction should be in
IT block -- `movcs r6,r0'
{standard input}:98: Error: thumb conditional instruction should be in
IT block -- `addcs r0,r8'
{standard input}:99: Error: thumb conditional instruction should be in
IT block -- `movcs r6,r0'
{standard input}:119: Error: thumb conditional instruction should be
in IT block -- `addcs r0,r8'
{standard input}:120: Error: thumb conditional instruction should be
in IT block -- `movcs r6,r0'
I am using the normal build (bootstrap.sh, configure, make) on Linaro
ALIP on the Beagleboard. The build worked fine on a Pandaboard with
Ubuntu 10.10. It looks like something is different and not being
detected via bootstrap/configure on ALIP.
I believe configure has identified the architecture correctly. Also, I
have searched and seen commits in the pulseaudio/ubuntu maillist
archive for adding -Wa, -mimplicit-it=thumb. I have added this to
CFLAGS without success.
Any thoughts on what else I could try?
What CFLAGS are you using? This should only turn up if you're compiling
that assembly in Thumb-2 mode.
I'm not sure if it would actually be desirable to compile in Thumb-2
mode for the OMAP3, but the correct fix for this would probably be to
add an ite cs before the addcs in svolume_arm.c. Could you test this
out (or let me know if you'd like a patch that does this)?
-- 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] Build assembler errors on ARM OMAP3
Here is the output of gcc -dumpspecs
http://pastebin.com/Z2ZDVrbc
Kurt Taylor (irc krtaylor)
On 17 February 2011 12:10, Kurt Taylor kurt.tay...@linaro.org wrote:
Thanks for your help Arun. I was finally able to come back to this
problem. Here is the last lines of a make on a clean git clone showing the
errors on the beagleboard (linaro ALIP).
Adding ite before the addcs did not build, adding itt built and ran, but
unloaded alsa module.
http://pastebin.com/Lqw0rEh9
Kurt Taylor (irc krtaylor)
On 14 February 2011 08:45, Arun Raghavan arun.ragha...@collabora.co.ukwrote:
On Mon, 2011-02-07 at 12:52 -0600, Kurt Taylor wrote:
I am seeing the following when trying to build pulseaudio on an
ARM-based Beagleboard (OMAP3):
CC libpulsecore_1.0_la-svolume_arm.lo
../libtool: line 975: warning: setlocale: LC_MESSAGES: cannot change
locale (en_GB.utf8)
{standard input}: Assembler messages:
{standard input}:82: Error: thumb conditional instruction should be in
IT block -- `addcs r0,r8'
{standard input}:83: Error: thumb conditional instruction should be in
IT block -- `movcs r6,r0'
{standard input}:98: Error: thumb conditional instruction should be in
IT block -- `addcs r0,r8'
{standard input}:99: Error: thumb conditional instruction should be in
IT block -- `movcs r6,r0'
{standard input}:119: Error: thumb conditional instruction should be
in IT block -- `addcs r0,r8'
{standard input}:120: Error: thumb conditional instruction should be
in IT block -- `movcs r6,r0'
I am using the normal build (bootstrap.sh, configure, make) on Linaro
ALIP on the Beagleboard. The build worked fine on a Pandaboard with
Ubuntu 10.10. It looks like something is different and not being
detected via bootstrap/configure on ALIP.
I believe configure has identified the architecture correctly. Also, I
have searched and seen commits in the pulseaudio/ubuntu maillist
archive for adding -Wa, -mimplicit-it=thumb. I have added this to
CFLAGS without success.
Any thoughts on what else I could try?
What CFLAGS are you using? This should only turn up if you're compiling
that assembly in Thumb-2 mode.
I'm not sure if it would actually be desirable to compile in Thumb-2
mode for the OMAP3, but the correct fix for this would probably be to
add an ite cs before the addcs in svolume_arm.c. Could you test this
out (or let me know if you'd like a patch that does this)?
-- 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] [RFC] Passthrough support
'Twas brillig, and Tanu Kaskinen at 17/02/11 17:17 did gyre and gimble: On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). Aargh! An unmatched left parenthesis creates an unresolved tension that will stay with me all day! And here you put TWO unmatched parentheses, I'll be tense also tomorrow :( Well, I think I can manage. Even more xkcd FTW :) Anyway, I think this is completely up to the routing logic. It should check the compatibility before doing the routing decision in the first place, if it is somehow aware of the possibility of incompatibility. This way there's no need to go back, which sounds very complicated. I think you're right, it would have to know about the compatibility before trying to move. I'm kinda thinking ahead to the priority list approach here, at present this is implemented pretty simply in that the check is simply is the device available, whereas with this new approach we'd have to check is the device available is it compatible with the input. This isn't too much extra logic or work so I think this makes sense. With the likes of passthrough, routing decisions would also have to check to see if the device is available to the degree that it's both present and does not already have a passthrough stream attached (and is thus operating in exclusive mode). So having such extra checks is going to be needed anyway. So I guess this all fits in nicely :) Take care (.. 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/2/17 Colin Guthrie gm...@colin.guthr.ie: There have been a few discussions recently about getting a solid roadmap organised for the next medium term of PA development. While the stable-queue stuff has been bubbling along nicely enough, there are several new features in the 1.x master branch but no real timescales decided. There are quite a few willing people out there these days which is really encouraging, but we need to get a solid focus on when to expect releases and what we hope to achieve in each one. This email is the start of that process. A solid plan for the next releases would indeed be very nice. With regards to IRC meeting, I propose initially that we do this next week sometime (the sooner the better). For the sake of argument, I'll pick a time: 11am UTC Thursday 24th. Other timing suggestions welcome. I'd expect it to take at least 1h but probably less than 2h and it would be good if people involved could be fairly focused during the meeting window. I'll prepare an agenda and ensure that notes/logs are taken (with a meetbot) and made available afterwords. We will likely use a new IRC channel for this but anyone who wants to sit in, lurk or actively particpate would be most welcome. Q: Is this time suitable for everyone (Lennart in particular)? I'll try to be there. I'm not sure if there is space on the agenda, but I'd like to discuss pavucontrol for a little bit. Not so much the current status, but rather what our vision is to what it should be, especially compared to the Gnome/KDE-specific alternatives. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
