Re: [pulseaudio-discuss] [PATCH] MP3 passthrough over A2DP (2nd version)
'Twas brillig, and Arun Raghavan at 08/02/11 17:09 did gyre and gimble: > On Fri, 2010-11-19 at 18:11 -0200, João Paulo Rechi Vita wrote: >> Hello Pierre, >> >> On Wed, Nov 10, 2010 at 17:00, pl bossart wrote: >>> Here's the corrected path with most comments from Tanu implemented. I >>> attached some additional gstreamer patches so that people can test the >>> actual functionality. >> >> As Tanu said previously, it seems the gstreamer patches didn't make to >> the list. Could you please make them available somehow? I'm also >> curious to test this. > > Hey Colin, are these still stuck in moderation somehow? Oops didn't reply :s Nothing in the moderation queue. We'll have to bug Pierre for the additional patches still :) 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] State of various rate adjustment patches
Yo, 'Twas brillig, and Maarten Bosmans at 09/02/11 16:07 did gyre and gimble: > 2011/1/31 Colin Guthrie : >> 'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble: >>> 2011/1/16 Maarten Bosmans : The branch is up at https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment ready for merging, as far a I am concerned. I'm still not entirely sure whether the change of https://github.com/mkbosmans/pulseaudio/commit/72b90ea8ac53e23862284991a2ce355de250f585 is correct, but it seems to avoid unnecessary rewinds for me. I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. >>> >>> There where no objections on the list, so I guess the branch at >>> https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment >>> can be merged with master. >> >> Cool, thanks Maaren. I'll pull in David's changes and then yours. > > On the issue of stable-queue: > > The first commit is definitaly a bugfix which should be included to > stable-queue > http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=11dbe30bfae09235307115f413fb6172df04a895 > > The second commit [8b4cb54595baeeb1d9b7d11a842ef7946e43a55a Limit rate > adjustments to small, inaudible jumps] has some fairly straightforward > logic which solves some bugs. I think this can go into stable, as > there is not much that can go wrong. > > As I have only tested the patches on two different network setups > (both wired, one busy and one without other traffic), I can't really > vouch for the next commits. I don't really expect any troubles, but > some testing by others would probably be warranted. Anyway, if you do > decide to include them into stable-queue, I'd lump the next three > commits together, ending with > 27db0603d6af7d25558af38ed525fc50330a9c32. > > As I said before, the last commit > [72b90ea8ac53e23862284991a2ce355de250f585] is really beyond my > understanding of rewinds and would definately not be appropriate for > stable-queue without further review. Also, it has not been tested in > combination with David's rewind patches, so that needs to be done too. As we discussed last night, we'll do another 0.9.x release and as such if you want to prep a stable queue branch I can merge with the necessary patches in it, then that would be awesome. If the sha1's cherry-pick cleanly then we can just do this on IRC interactively and I'll push it out like that for more testing. If you want to discuss more, just ping me. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Properties to suppress save/restore of stream volumes
'Twas brillig, and Arun Raghavan at 08/02/11 15:34 did gyre and gimble: > If there are no objections to this approach, we could expose the fading > API via a property (set it to trigger a fade) and a signal (for the > fade-done callback). > > For the completion notification, I realised we would just pass the > callback to the _set_volume_with_ramping() function like the rest of the > API, so nothing new needs to be done for that it seems. > > Now all that remains is to figure out whether this belongs in core or in > an extension. I think it fits in core (a _with_ramping variant of > existing core API), but I'm not a religious about it. :) Just to revive this thread since our meeting Now that we know the ramping stuff will be ripped out for 1.0 release (by your good self Arun!), I guess we can put this on the back burner for now? 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] Alsa UCM integration.
Sorry I couldn't make the meeting yesterday. On Thu, 2011-02-24 at 23:34 -0600, Margarita Olaya wrote: > Pierre, > > On Thu, Feb 24, 2011 at 2:20 PM, pl bossart wrote: > >> The initial version of the UCM module is available at the following link: > >> http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module > >> > >> I'm still working in the module, It is work in progress to verify the > >> current verb when the stream is closed, also it is needed to add more > >> code to work with the profiles and the use cases. Sink, source and > >> device data could be taken from the proplist of the verb, and this is > >> pending too. > > > > Hi Margarita, > > I looked at your patches and have the following comments: > > Thanks for the review and feedback on the meeting. > > > - any reason why your version of PulseAudio is 1.3 years old. The > > previous patches on your branch are from 2009-11-18, quite a while > > ago. It'll make upstreaming difficult. > > Well, I had some troubles at the begging so I started by taking an > stable rls but for sure I'll move soon the code to latest commit > before upstream it. > > > - you now have a separate module-alsa-ucm module, but it's called with > > a device name as a parameter. So if I have one USB headphone and one > > USB mic, this module will be called twice. It's not clear to me then > > how the virtual device would be handled, and how this is different > > from inserting all the code in module-alsa-card as you did it in your > > previous version? > > the idea was to have at least one card working, so yes this is pretty > much the same approach than the code in module-alsa-card. Do you have > any idea on how to manage virtual cards? I'm not clear on they way > that ALSA manages virtual cards. > > > - can you explain why you set the verb using the hook > > PA_CORE_HOOK_SINK_INPUT_NEW, with priority PA_HOOK_EARLY+15. There are > > other audio-policy related modules that may use different hooks, such > > as PA_CORE_HOOK_SINK_INPUT_PUT. I would think you want to set the verb > > at the UCM level after all this logic has made decisions, at the last > > possible moment before data start flowing. > > The initial approach was a bit different but after the IRC discussion > I agree to use a different hook so verb will be set after all the > analysis with profiles has been done but it is needed first to map a > profile with a verb instead of the current approach with roles. > > > - how do we make use of modifiers? > I have not really thought about this. > Modifiers can be used in the following situations:- 1) Music is being played. Pulseaudio has configured the Music use case verb via UCM. The system wants to play a tone, this could be a beep or even a ring tone for an incoming call. Pulseaudio would then check for a UCM "play tone" modifier for the current verb and then enable the modifier if it exists. This "play tone" modifier would setup the hardware to play both Music (i.e the verb) and additionally tones (the modifier). The modifier may use a different ALSA pcm and hardware volume controls to that of the main verb. If no "play tone" modifier exists then Pulsewould mix the tone into the music being played in software as it does atm. 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM verb. The user wants to play music on the phone call. The modifier would be "Music" so Pulseaudio will check that a modifier exist for this when the phone call verb is active and enable this modifier. If no music modifier is available in the phone call verb configuration then pulseaudio would mix the music and voice in software. Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log feature
>From: Maarten Bosmans [mailto:mkbosm...@gmail.com]
>Sent: Friday, February 25, 2011 1:10 AM
>To: Becker, VincentX
>Cc: General PulseAudio Discussion
>Subject: Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log
>feature
>
>The patches were handled at the meeting yesterday
>http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-
>meeting.2011-02-24-21.02.html
>
>Some changes are necessary, but basically adding the file log target
>is ACKed. The other change about string format handling needs further
>review though.
>
>If you need some help with getting patches ready, I can be of
>assistance, just let me know.
>
>Maarten
Hi Maarten,
I checked the review comments and there are quite few things I don't fully
know/understand. It is spoken about rotation logic at some time. What does it
mean exactly ? And Lennart used the "s-o-b" acronym; what does it mean ? ("we
don't do s-o-b btw"). I fully agree with the changes proposed and will do them
and resend (1 or 2 ?) patches. It should be Ok for the patch generation, I will
dig the subject.
However the second one needs still to wait to be reviewed, right ?
Thanks
Vincent
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log feature
>-Original Message- >From: pulseaudio-discuss-boun...@mail.0pointer.de [mailto:pulseaudio- >discuss-boun...@mail.0pointer.de] On Behalf Of Paul Menzel >Sent: Thursday, February 24, 2011 11:15 PM >To: pulseaudio-discuss@mail.0pointer.de >Subject: Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log >feature > >Dear VincentX, > > >please note in the subject what iteration your patch is, e. g. »[PATCH >1/2 v2]«. See `--subject-prefix` in `git help format-patch`. Ok I will check this. Also I will include an example in the commit message. > >Am Donnerstag, den 24.02.2011, 16:30 + schrieb Becker, VincentX: >> From 55f84afd8575dadba697c746daa61ee07b333c57 Mon Sep 17 00:00:00 2001 >> From: Vincent Becker >> Date: Thu, 24 Feb 2011 16:52:05 +0100 >> Subject: [PATCH] Add a new log target to a file descriptor in daemon >> configuration >> Signed-off-by: Vincent Becker This >> patches adds the option to log pulseaudio messages into a file >descriptor. > >Could you add that indentation change in a separate patch? It makes it >easier to review in my opinion. It is not necessary though. Uh.. > >[…] > >Could you also document the new option in the manual and add an example >to it? Do the config file templates also need to be updated? How do I update this manual ? I need to do some changes before redelivering the patches and I will check the config file templates as well. Thx. Vincent > > >Thanks, > >Paul - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log feature
2011/2/25 Becker, VincentX :
>>From: Maarten Bosmans [mailto:mkbosm...@gmail.com]
>>Sent: Friday, February 25, 2011 1:10 AM
>>To: Becker, VincentX
>>Cc: General PulseAudio Discussion
>>Subject: Re: [pulseaudio-discuss] [PATCH 1/2] Add a target to the PA log
>>feature
>>
>>The patches were handled at the meeting yesterday
>>http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-
>>meeting.2011-02-24-21.02.html
>>
>>Some changes are necessary, but basically adding the file log target
>>is ACKed. The other change about string format handling needs further
>>review though.
>>
>>If you need some help with getting patches ready, I can be of
>>assistance, just let me know.
>>
>>Maarten
>
> Hi Maarten,
> I checked the review comments and there are quite few things I don't fully
> know/understand. It is spoken about rotation logic at some time. What does it
> mean exactly ?
That's about adding the date to the filename. We don't want to become
like logrotate. Just use the filename given by
--log-target=file:filename
> And Lennart used the "s-o-b" acronym; what does it mean ? ("we don't do s-o-b
> btw"). I fully agree with the changes proposed and will do them and resend (1
> or 2 ?) patches. It should be Ok for the patch generation, I will dig the
> subject.
signed-off-by: we don't use that here, that's more of a kernel thing.
> However the second one needs still to wait to be reviewed, right ?
Yeah, so make the first patch a complete implementation of the logging
to fd, but without any reworking of the way the log messages are
formatted, etc. Then if there are any problems with the second patch,
the first can still be applied to master.
> Thanks
> Vincent
>
>
> -
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number: 302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Properties to suppress save/restore of stream volumes
On Fri, 2011-02-25 at 09:42 +, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 08/02/11 15:34 did gyre and gimble: > > If there are no objections to this approach, we could expose the fading > > API via a property (set it to trigger a fade) and a signal (for the > > fade-done callback). > > > > For the completion notification, I realised we would just pass the > > callback to the _set_volume_with_ramping() function like the rest of the > > API, so nothing new needs to be done for that it seems. > > > > Now all that remains is to figure out whether this belongs in core or in > > an extension. I think it fits in core (a _with_ramping variant of > > existing core API), but I'm not a religious about it. :) > > Just to revive this thread since our meeting > > Now that we know the ramping stuff will be ripped out for 1.0 release > (by your good self Arun!), I guess we can put this on the back burner > for now? Oh, the irony! :) Yep, this will need to fade (:p) to the background. Pity, since the gst side power optimisation also gets postponed as a result, but hopefully it'll be something we can get back to soon after 1.0 (I'm an optimist! :D). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Properties to suppress save/restore of stream volumes
'Twas brillig, and Arun Raghavan at 25/02/11 10:40 did gyre and gimble: > Oh, the irony! :) Yep, this will need to fade (:p) to the background. > Pity, since the gst side power optimisation also gets postponed as a > result, but hopefully it'll be something we can get back to soon after > 1.0 (I'm an optimist! :D). Pun-tastic! Yeah, we can probably have another meeting regarding how best to fit into Lennart's world view of the "filter" implementation and then work out how best to add ramping after that. But it can wait a few months at least. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)
Forgive my ignorance of how the virtual-sink.c works (I've really not looked) but my (perhaps incorrect) understanding was that it is basically a code template rather than a real sink. Is this just a wrong grasp of the situation? If it's not wrong, should the changes there to modargs etc. be migrated to the modules which have been spawned from virtual sink? Or should we try to come up with a better inheritance mechanism... perhaps we should switch to C++? :p (that was a joke btw!) /me really needs to read up more on the virtual sink stuff Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] RFC: Adding hooks for port+profile changes (possibly UCM related)
Hi,
A while ago a user needed to get notification (in a module) when a sink
port changed.. I recommended he added a simple patch for this to add a
new hook which he implemented. I'm only now getting around to merging
(sorry kt)
I extended this a little to add a similar hook when the card profile
changed. I've pasted both below for review (they are simple).
I guess this could be used in UCM such that a ucm module could listen
for changes to ports then push the verb to ALSA as appropriate... Just
double checking that this is sensible before I push it but I think it
makes sense to have this :)
commit 9379d4015c48ed15a9f5bde8dac085dbca08bea3
Author: Kim Therkelsen
Date: Fri Oct 15 09:25:12 2010 +0200
core: Added new hooks: PA_CORE_HOOK_SOURCE_PORT_CHANGED and
PA_CORE_HOOK_SINK_PORT_CHANGED
This allows modules to know when certain ports are changed.
This will allow e.g. a filter module (or LADSAP) to only load
when a certain port is used on the device (e.g. to only filter
headphones and not normal speakers).
(Comment from Colin Guthrie: This may also have use in UCM)
diff --git a/src/pulsecore/core.h b/src/pulsecore/core.h
index a1215bb..daa89c1 100644
--- a/src/pulsecore/core.h
+++ b/src/pulsecore/core.h
@@ -74,6 +74,7 @@ typedef enum pa_core_hook {
PA_CORE_HOOK_SINK_UNLINK_POST,
PA_CORE_HOOK_SINK_STATE_CHANGED,
PA_CORE_HOOK_SINK_PROPLIST_CHANGED,
+PA_CORE_HOOK_SINK_PORT_CHANGED,
PA_CORE_HOOK_SOURCE_NEW,
PA_CORE_HOOK_SOURCE_FIXATE,
PA_CORE_HOOK_SOURCE_PUT,
@@ -81,6 +82,7 @@ typedef enum pa_core_hook {
PA_CORE_HOOK_SOURCE_UNLINK_POST,
PA_CORE_HOOK_SOURCE_STATE_CHANGED,
PA_CORE_HOOK_SOURCE_PROPLIST_CHANGED,
+PA_CORE_HOOK_SOURCE_PORT_CHANGED,
PA_CORE_HOOK_SINK_INPUT_NEW,
PA_CORE_HOOK_SINK_INPUT_FIXATE,
PA_CORE_HOOK_SINK_INPUT_PUT,
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index 0de544c..773123d 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -2700,6 +2700,8 @@ int pa_sink_set_port(pa_sink *s, const char *name,
pa_bool_t save) {
s->active_port = port;
s->save_port = save;
+pa_hook_fire(&s->core->hooks[PA_CORE_HOOK_SINK_PORT_CHANGED], s);
+
return 0;
}
diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
index 24d0ff6..a553662 100644
--- a/src/pulsecore/source.c
+++ b/src/pulsecore/source.c
@@ -1571,5 +1571,7 @@ int pa_source_set_port(pa_source *s, const char
*name, pa_bool_t save) {
s->active_port = port;
s->save_port = save;
+pa_hook_fire(&s->core->hooks[PA_CORE_HOOK_SOURCE_PORT_CHANGED], s);
+
return 0;
}
commit 9e2aec6a66dde80f63171a2ad15ac74d34678560
Author: Colin Guthrie
Date: Fri Feb 25 10:27:23 2011 +
core: Add a new hook PA_CORE_HOOK_CARD_PROFILE_CHANGED
This will allow modules to know when a card profile has changed
and take appropriate action. This might prove useful when developing
UCM so that the appropriate verb can be set.
diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
index 2f0a3af..1758f48 100644
--- a/src/pulsecore/card.c
+++ b/src/pulsecore/card.c
@@ -214,6 +214,7 @@ int pa_card_set_profile(pa_card *c, const char
*name, pa_bool_t save) {
pa_card_profile *profile;
int r;
pa_assert(c);
+pa_assert(c->core);
if (!c->set_profile) {
pa_log_debug("set_profile() operation not implemented for card
%u \"%s\"", c->index, c->name);
@@ -241,6 +242,8 @@ int pa_card_set_profile(pa_card *c, const char
*name, pa_bool_t save) {
c->active_profile = profile;
c->save_profile = save;
+pa_hook_fire(&c->core->hooks[PA_CORE_HOOK_CARD_PROFILE_CHANGED], c);
+
return 0;
}
diff --git a/src/pulsecore/core.h b/src/pulsecore/core.h
index daa89c1..358b98d 100644
--- a/src/pulsecore/core.h
+++ b/src/pulsecore/core.h
@@ -113,6 +113,7 @@ typedef enum pa_core_hook {
PA_CORE_HOOK_CARD_NEW,
PA_CORE_HOOK_CARD_PUT,
PA_CORE_HOOK_CARD_UNLINK,
+PA_CORE_HOOK_CARD_PROFILE_CHANGED,
PA_CORE_HOOK_MAX
} pa_core_hook_t;
--
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: Adding hooks for port+profile changes (possibly UCM related)
'Twas brillig, and Colin Guthrie at 25/02/11 11:23 did gyre and gimble:
> diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
> index 2f0a3af..1758f48 100644
> --- a/src/pulsecore/card.c
> +++ b/src/pulsecore/card.c
> @@ -214,6 +214,7 @@ int pa_card_set_profile(pa_card *c, const char
> *name, pa_bool_t save) {
> pa_card_profile *profile;
> int r;
> pa_assert(c);
> +pa_assert(c->core);
>
> if (!c->set_profile) {
> pa_log_debug("set_profile() operation not implemented for card
> %u \"%s\"", c->index, c->name);
Oops, this assert is not needed (doesn't hurt tho') I didn't mean to
commit it. Removed from my tree now.
But the "is this sensible"? question still remains :)
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Windows binaries
As the patches that make it possible to build pulse on win32 should land in master any moment now, I thought it would be a good time to make the binaries available for download. http://bosmans.ch/pulseaudio/pulseaudio-1.0dev-1090.4.zip This is just a repackaging of the files found at https://build.opensuse.org/project/monitor?package=&project=home%3Amkbosmans%3Amingw32%3Apulseaudio , for ease of use on Windows. You can start the daemon with bin\pulseaudio.exe -vvv -p \_ABS_PATH_TO_\pulseaudio-1.0dev-1090.4\lib\pulse-1.0\modules -nF etc\pulse\default.pa The paths need to be provided, because the compiled in defaults are meaningless on windows. This means there is still some work to do on the win32 front. As there were some inquiries about the binaries on irc a couple of days ago, its probably a good idea to also mention the new (unstable) build on the wiki. Is there also a possibility to host the zipfile on some 'official' pulsed server for download, or should I just host them myself, just like Cendia does for the old 0.9.6 binaries? I don't think you can upload files to the wiki. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Windows binaries
'Twas brillig, and Maarten Bosmans at 25/02/11 13:28 did gyre and gimble: > Is there also a possibility to host the zipfile on > some 'official' pulsed server for download, or should I just host them > myself, just like Cendia does for the old 0.9.6 binaries? I don't > think you can upload files to the wiki. Yeah it's best to self host for now. Once we get on to fd.o we can make this more official. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa-mixer: Fix path set building when using the element-output or element-input mapping options in profile set configuration.
When creating synthesized paths, pa_alsa_path_set_new() created duplicate
elements for each path, and one of the duplicate elements would be marked as
required absent. That made path probing fail. While debugging this, I noticed
also that pa_alsa_path_synthesize() didn't initialize p->last_element properly.
---
src/modules/alsa/alsa-mixer.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index 91e17de..e156096 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -1992,6 +1992,7 @@ pa_alsa_path* pa_alsa_path_synthesize(const char*element,
pa_alsa_direction_t di
e->volume_use = PA_ALSA_VOLUME_MERGE;
PA_LLIST_PREPEND(pa_alsa_element, p->elements, e);
+p->last_element = e;
return p;
}
@@ -2390,6 +2391,10 @@ pa_alsa_path_set *pa_alsa_path_set_new(pa_alsa_mapping
*m, pa_alsa_direction_t d
/* Mark all other passed elements for require-absent */
for (je = en; *je; je++) {
pa_alsa_element *e;
+
+if (je == ie)
+continue;
+
e = pa_xnew0(pa_alsa_element, 1);
e->path = p;
e->alsa_name = pa_xstrdup(*je);
--
1.7.3.4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa-card: Add a new modarg "profile_set" for giving the card a custom profile set configuration file.
---
src/modules/alsa/module-alsa-card.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index ebd2f8a..3f8576d 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -65,7 +65,8 @@ PA_MODULE_USAGE(
"tsched_buffer_watermark= "
"profile= "
"ignore_dB= "
-"sync_volume=");
+"sync_volume= "
+"profile_set= ");
static const char* const valid_modargs[] = {
"name",
@@ -88,6 +89,7 @@ static const char* const valid_modargs[] = {
"profile",
"ignore_dB",
"sync_volume",
+"profile_set",
NULL
};
@@ -328,6 +330,11 @@ int pa__init(pa_module *m) {
fn = pa_udev_get_property(alsa_card_index, "PULSE_PROFILE_SET");
#endif
+if (pa_modargs_get_value(ma, "profile_set", NULL)) {
+pa_xfree(fn);
+fn = pa_xstrdup(pa_modargs_get_value(ma, "profile_set", NULL));
+}
+
u->profile_set = pa_alsa_profile_set_new(fn,
&u->core->default_channel_map);
pa_xfree(fn);
--
1.7.3.4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6] Implement the "volume sharing" feature.
On Thu, 2011-02-24 at 16:16 +0200, Tanu Kaskinen wrote:
> 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).
I almost forgot to give credit to Marc-André Lureau, who wrote the first
version of this patch a long time ago. So, Colin, if you commit this
patch, please add the following text to the commit message:
"""
This patch is based on the work of Marc-André Lureau, who did the
initial implementation for Pulseaudio 0.9.15.
"""
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-card: Add a new modarg "profile_set" for giving the card a custom profile set configuration file.
'Twas brillig, and Tanu Kaskinen at 25/02/11 14:28 did gyre and gimble: > --- > src/modules/alsa/module-alsa-card.c |9 - > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/src/modules/alsa/module-alsa-card.c > b/src/modules/alsa/module-alsa-card.c > index ebd2f8a..3f8576d 100644 > --- a/src/modules/alsa/module-alsa-card.c > +++ b/src/modules/alsa/module-alsa-card.c > @@ -65,7 +65,8 @@ PA_MODULE_USAGE( > "tsched_buffer_watermark= " > "profile= " > "ignore_dB= " > -"sync_volume="); > +"sync_volume= " > +"profile_set= "); Yeah this seems like a useful argument for debugging without having to go though dbus config etc. Applied. COl -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Fix path set building when using the element-output or element-input mapping options in profile set configuration.
'Twas brillig, and Tanu Kaskinen at 25/02/11 14:27 did gyre and gimble: > When creating synthesized paths, pa_alsa_path_set_new() created duplicate > elements for each path, and one of the duplicate elements would be marked as > required absent. That made path probing fail. Not sure I fully appreciate this as I've not really studied that code, but I trust you :) Applied. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Pulseaudio input mixer rewrite
'Twas brillig, and David Henningsson at 19/01/11 15:59 did gyre and gimble: > Yeah, I guess it's time. Let me know if you want six emails instead of one. OK, I've applied this to my tree now. Just need to do a bit of testing before I can happily push it out :) One of the patches conflicted with this, so I guess your tree was a little out of date, but I was able to adapt it easily enough (just added the new rounding argument to the two additional calls that were added - I presume this is sufficient but you may want to double check that there are no other occurrences that need patching (I didn't find any). commit 1bea9558297773fd2e2fe4deb43a5adabf90a16e Author: Jyri Sarha Date: Fri Oct 15 13:05:15 2010 +0300 alsa: Take syncronized HW volume infra into use for alsa-sink Signed-off-by: Jyri Sarha Reviewed-by: Tanu Kaskinen Reviewd-by: Colin Guthrie With any luck I'll be able to test soon and get it pushed. 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] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)
On Fri, 2011-02-25 at 11:14 +, Colin Guthrie wrote: > Forgive my ignorance of how the virtual-sink.c works (I've really not > looked) but my (perhaps incorrect) understanding was that it is > basically a code template rather than a real sink. > > Is this just a wrong grasp of the situation? Well, it is a template, but it's also fully functional. The functionality is just very limited :) > If it's not wrong, should the changes there to modargs etc. be migrated > to the modules which have been spawned from virtual sink? I believe there aren't actually any modules yet spawned from the virtual sink. But your point is still valid - if you think the changes that I made for module-virtual-sink are useful for other filter sinks, feel free to modify those other sinks too. I don't think that at least the force_flat_volume option is generally of much use, though - I added it to module-virtual-sink just so that I could easily have both flat volume and non-flat volume sinks for testing stream moving between the two sink types. I could have copied module-virtual-sink into a new module, maybe called module-filter-test-sink, in the name of keeping the template module cleaner, but I thought that would be too much redundancy just for some simple debug options in module-virtual-sink. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6] Implement the "volume sharing" feature.
'Twas brillig, and Tanu Kaskinen at 25/02/11 15:44 did gyre and gimble: > I almost forgot to give credit to Marc-André Lureau, who wrote the first > version of this patch a long time ago. So, Colin, if you commit this > patch, please add the following text to the commit message: > > """ > This patch is based on the work of Marc-André Lureau, who did the > initial implementation for Pulseaudio 0.9.15. > """ elmarco FTW! Are you happy with the patch other than this additional comment in the commit message? 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] Alsa UCM integration.
> Modifiers can be used in the following situations:- > > 1) Music is being played. Pulseaudio has configured the Music use case > verb via UCM. The system wants to play a tone, this could be a beep or > even a ring tone for an incoming call. Pulseaudio would then check for a > UCM "play tone" modifier for the current verb and then enable the > modifier if it exists. This "play tone" modifier would setup the > hardware to play both Music (i.e the verb) and additionally tones (the > modifier). The modifier may use a different ALSA pcm and hardware volume > controls to that of the main verb. > > If no "play tone" modifier exists then Pulsewould mix the tone into the > music being played in software as it does atm. > > 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM > verb. The user wants to play music on the phone call. The modifier would > be "Music" so Pulseaudio will check that a modifier exist for this when > the phone call verb is active and enable this modifier. > > If no music modifier is available in the phone call verb configuration > then pulseaudio would mix the music and voice in software. Make sense. But I am not sure the profiles as defined today in PulseAudio can work with modifiers. What we discussed yesterday is that when a profile is selected then you would set the UCM verb and know about all possible sinks. We would need additional logic to have profile modifiers, or we would need extra profiles to represent all possible combinations (speech, speech+tone, speech+music, etc). -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)
> Well, it is a template, but it's also fully functional. The > functionality is just very limited :) > >> If it's not wrong, should the changes there to modargs etc. be migrated >> to the modules which have been spawned from virtual sink? > > I believe there aren't actually any modules yet spawned from the virtual > sink. We have internal modules based on the virtual sink. I guess the echo canceler was also derived from the same concept. And it was based on the LADSPA sink in the first place. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual Sink Template (was Re: [PATCH 6/6] virtual-sink: Fix a crash when moving the sink to a new master right after setup.)
'Twas brillig, and pl bossart at 25/02/11 16:13 did gyre and gimble: >> Well, it is a template, but it's also fully functional. The >> functionality is just very limited :) >> >>> If it's not wrong, should the changes there to modargs etc. be migrated >>> to the modules which have been spawned from virtual sink? >> >> I believe there aren't actually any modules yet spawned from the virtual >> sink. > > We have internal modules based on the virtual sink. I guess the echo > canceler was also derived from the same concept. And it was based on > the LADSPA sink in the first place. And there is also the equalizer-sink module too. So... Hmm, probably worth thinking about this post-1.0 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: Adding hooks for port+profile changes (possibly UCM related)
On Fri, 2011-02-25 at 11:29 +, Colin Guthrie wrote:
> 'Twas brillig, and Colin Guthrie at 25/02/11 11:23 did gyre and gimble:
> > diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
> > index 2f0a3af..1758f48 100644
> > --- a/src/pulsecore/card.c
> > +++ b/src/pulsecore/card.c
> > @@ -214,6 +214,7 @@ int pa_card_set_profile(pa_card *c, const char
> > *name, pa_bool_t save) {
> > pa_card_profile *profile;
> > int r;
> > pa_assert(c);
> > +pa_assert(c->core);
> >
> > if (!c->set_profile) {
> > pa_log_debug("set_profile() operation not implemented for card
> > %u \"%s\"", c->index, c->name);
>
> Oops, this assert is not needed (doesn't hurt tho') I didn't mean to
> commit it. Removed from my tree now.
>
> But the "is this sensible"? question still remains :)
Yes, I think it's very sensible. Ship it :)
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Fri, 2011-02-25 at 10:10 -0600, pl bossart wrote: > > Modifiers can be used in the following situations:- > > > > 1) Music is being played. Pulseaudio has configured the Music use case > > verb via UCM. The system wants to play a tone, this could be a beep or > > even a ring tone for an incoming call. Pulseaudio would then check for a > > UCM "play tone" modifier for the current verb and then enable the > > modifier if it exists. This "play tone" modifier would setup the > > hardware to play both Music (i.e the verb) and additionally tones (the > > modifier). The modifier may use a different ALSA pcm and hardware volume > > controls to that of the main verb. > > > > If no "play tone" modifier exists then Pulsewould mix the tone into the > > music being played in software as it does atm. > > > > 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM > > verb. The user wants to play music on the phone call. The modifier would > > be "Music" so Pulseaudio will check that a modifier exist for this when > > the phone call verb is active and enable this modifier. > > > > If no music modifier is available in the phone call verb configuration > > then pulseaudio would mix the music and voice in software. > > Make sense. > But I am not sure the profiles as defined today in PulseAudio can work > with modifiers. What we discussed yesterday is that when a profile is > selected then you would set the UCM verb and know about all possible > sinks. We would need additional logic to have profile modifiers, or we > would need extra profiles to represent all possible combinations > (speech, speech+tone, speech+music, etc). Yeah, I'm thinking it may be easier to add the extra profiles here. We could match a profile and it's UCM verb+modifier at init time. Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
> the idea was to have at least one card working, so yes this is pretty > much the same approach than the code in module-alsa-card. Do you have > any idea on how to manage virtual cards? I'm not clear on they way > that ALSA manages virtual cards. I am not clear either. I asked a question on this on alsa-devel, but the answer from Jaroslav was quite short. I am still unsure how you actually know when a virtual card is present. I hoped someone could explain the concept in practical terms, looks like we are all lost here. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6] Implement the "volume sharing" feature.
On Fri, 2011-02-25 at 16:05 +, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 25/02/11 15:44 did gyre and gimble: > > I almost forgot to give credit to Marc-André Lureau, who wrote the first > > version of this patch a long time ago. So, Colin, if you commit this > > patch, please add the following text to the commit message: > > > > """ > > This patch is based on the work of Marc-André Lureau, who did the > > initial implementation for Pulseaudio 0.9.15. > > """ > > elmarco FTW! > > Are you happy with the patch other than this additional comment in the > commit message? Well, I'm not very happy with the complexity that it introduces, but I'm as happy as I can be without somehow redesigning the whole volume system. So feel free to commit it. (Reviewing would still be nice, just as with any other patch - reviewing this one probably isn't fun at all, though.) -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6] Implement the "volume sharing" feature.
Hi guys! On Fri, Feb 25, 2011 at 5:05 PM, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 25/02/11 15:44 did gyre and gimble: > Are you happy with the patch other than this additional comment in the > commit message? Thanks Tanu for giving me my share of credits :) my 2c, although it's been almost two years since I started this patch, I remember I was convince that it was the right approach, in my mind, it simplified the volume computation in "complex graph" cases (and also some weird crazy volume computation loops when you have 3 sinks in Y shape that should really just be the same volume in fact - that's why it was call flat-sink originally). But I never managed (or had time really) to properly put those reasons into words, and convince Lennart, with whom I discussed it, but there is no written trace of that discussion, I don't think it was even submitted on the ML. So, although it looks weird, this patch (or it's version on N900) is fairly safe and solve some real use cases. There is no obvious way to improve it. If it can help Nokia and other people to get this in (instead of having to maintain it elsewhere), I would say go for it, yes! regards -- Marc-André Lureau ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
> Make sense. > But I am not sure the profiles as defined today in PulseAudio can work > with modifiers. What we discussed yesterday is that when a profile is > selected then you would set the UCM verb and know about all possible > sinks. We would need additional logic to have profile modifiers, or we > would need extra profiles to represent all possible combinations > (speech, speech+tone, speech+music, etc). The initial idea is to use the UCM data to generate the card profiles, then when the stream is open PA will use his method to select the profile and set the verb. e.g when UCM is present: profile = verb. In the UCM module the data is store in a proplist per verb, the proplist has the following info: PA_PROP_UCM_SINK -> "PlaybackPCM" PA_PROP_UCM_SOURCE -> "CapturePCM" PA_PROP_UCM_PLAYBACK_VOLUME -> "PlaybackVolume" PA_PROP_UCM_PLAYBACK_SWITCH -> "PlaybackSwitch" PA_PROP_UCM_CAPTURE_VOLUME -> "CaptureVolume" PA_PROP_UCM_CAPTURE_SWITCH -> "CaptureSwitch" PA_PROP_UCM_QOS -> "TQ" plus the list of devices e.g headphone, headset and modifiers e.g "play tone", "play music", etc. Also, each profile has some on the following fields: [Mapping id] e.g analog-mono device-strings = hw:%f e.g hw:0 where %f is the card identifier channel-map = e.g mono defined in src/pulse/channelmap.c paths input/ouput = priority direction = in some cases it doesn't have the channel-map it only has the direction The profiles are probed and initialized in module-alsa-card @pa__init, when ucm is present instead of taking the data from default.conf and probe everything, when no rule is defined, the ucm data comes to scene. Now, I would like to get some suggestion on how to map the data, at least I can see that device-strings correspond PlaybackPCM or CapturePCM. Thanks & Regards, Margarita ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
