Re: [pulseaudio-discuss] [PACKAGERS] New dep
'Twas brillig, and Maarten Bosmans at 26/05/11 15:23 did gyre and gimble: > 2011/5/16 Colin Guthrie : >> Hi, >> >> I've just pushed Arun's (mostly, Pierre-Louis also had a hand!) >> passthrough work to master. >> >> This carries with it a new dependency: json-c > > What is the upstream location of that software? Googling for json > implementations gives a lot of small libraries, it is not clear which > one is needed as the pulse dep. > > I guess it could be the one at http://oss.metaparadigm.com/json-c/, > but that website is out of order for some time now. The .tar file is > only locatable through the packaging systems of various Linux > distros/BSDs. > > Needless to say, such an unclear status of a dependency is not really > helpfull in packaging PulseAudio. I dunno, we already had a package in Mandriva and I just updated it to the latest version from the Fedora package. Arun, do you have more definitive info? 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] fix the assumption that volume is always positive
'Twas brillig, and Tanu Kaskinen at 26/05/11 13:48 did gyre and gimble: > On Thu, 2011-05-26 at 14:08 +0300, Tanu Kaskinen wrote: >> On Thu, 2011-05-26 at 09:50 +0100, Colin Guthrie wrote: >>> 'Twas brillig, and Lu Guanqun at 26/05/11 09:49 did gyre and gimble: >>>> Add a variable to track whether the actual volume is set or not. >>>> Suppose this: >>>>min volume: -126max volume: 0 >>>> then when user wants to set some constant volume to -10, it would fail. >>> >>> Tanu, are you OK with this patch? >> >> Maybe, maybe not. I posted a question to alsa-devel: >> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-May/040213.html >> >> If negative steps are allowed, I expect there to be more bugs. > > I got a confirmation that negative volumes are allowed, so the patch > should be fine. Somebody should review the alsa mixer code for other > cases of the invalid assumption (I plan to do it in the indefinite > future, if nobody else does it). OK, sounds good. I will queue it up at my end. Judging by Takashi's comments on alsa-devel, in an ideal world the driver would be updated too to avoid the use of the negative steps (which is "funky" :p), but we still need this fix all the same. Thanks for the patch. 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] How to change profile of bluetooth headset for different applications?
'Twas brillig, and Tanu Kaskinen at 26/05/11 13:08 did gyre and gimble:
> On Mon, 2011-05-23 at 18:18 +0100, Colin Guthrie wrote:
>> How about this:
>>
>> Define a new card property similar in concept to
>> PA_PROP_DEVICE_INTENDED_ROLES ("device.intended_roles") called
>> PA_PROP_DEVICE_INTENDED_PROFILE ("device.intended_profile").
>>
>> In bluetooth device, when loading a headset that has both HSP and A2DP,
>> populate the device with the following code:
>>
>> if (supports_hsp && supports_a2dp)
>> {
>> char *k;
>>
>> k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "music");
>> pa_proplist_sets(card_data.proplist, k, "a2dp");
>> pa_xfree(k);
>>
>> k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "video");
>> pa_proplist_sets(card_data.proplist, k, "a2dp");
>> pa_xfree(k);
>>
>> k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, "phone");
>> pa_proplist_sets(card_data.proplist, k, "hsp");
>> pa_xfree(k);
>> }
>>
>> This should result in "pacmd list-cards" dumping a proplist that includes:
>>
>> device.intended_profile.music = a2dp
>> device.intended_profile.video = a2dp
>> device.intended_profile.phone = hsp
>>
>>
>>
>> Then a separate module (module-intended-profiles?) could take care of
>> listening quite generically for streams landing on sink and do the
>> following logic:
>>
>>
>> if (!si->sink || !si->sink->card)
>> return PA_HOOK_OK;
>>
>> char *role = pa_proplist_gets(si->proplist, PA_PROP_MEDIA_ROLE);
>> if (!role)
>> return PA_HOOK_OK;
>>
>> char *k = pa_sprintf_malloc("%s.%s", PA_PROP_DEVICE_INTENDED_PROFILE, role);
>> pa_card *card = si->sink->card;
>> char *profile = pa_proplist_gets(card->proplist, k);
>> pa_xfree(k);
>> if (!profile)
>> return PA_HOOK_OK;
>>
>> if (!pa_streq(card->active_profile, profile)) {
>>/* Save the current profile for later restoration */
>>...
>>
>>if (pa_card_set_profile(card, profile, FALSE) < 0)
>>/* Find the sink of this card as the above call will likely have
>> changed it */
>>sink = pa_idxset_first(card->sinks, NULL);
>>
>>pa_sink_input_move_to(si, sink, FALSE);
>> }
>>
>>
>> This code is then completely generic. I'm not 100% sure how well this
>> will work in practice as there may be some nasty races etc. but I think
>> this general approach could work... Perhaps others (i.e. Tanu :D) have
>> better suggestions?
>
> If the priority lists would exist already, the module deciding the
> routing could examine the stream properties and pick the sink+port with
> the highest priority that can be made available - if the sink+port isn't
> immediately available, but can be made available, then the routing
> module would change the profile and port as needed.
Cool, sounds good to me.
> But the priority lists are not available. I believe the logic that you
> propose is otherwise good, except that I don't see how the stream could
> "land" on the bluetooth (a2dp) sink automatically on phone calls.
> module-bluetooth-device tags only hsp sinks with the phone tag, not a2dp
> sinks, so module-intended-roles can't do the required magic. If the hsp
> sink doesn't exist because the a2dp profile is selected, I don't think
> there's currently any logic to route the stream to the bluetooth sink.
> If, however, by some magic the phone stream would be routed to the a2dp
> sink, then I think your proposal would work fine.
Some of Amanda's earlier emails on this list were about other modules
tweaks (namely to switch-on-connect) to force the use of the bluetooth
device more strongly that module-intended-roles currently does, so I
suspect that the "making the stream use the bluetooth device in any
mode" problem is already solved for them.
> For better suggestions, I don't think I have any. Except that use the
> policy framework - Lin posted from an intel.com address, so I assume he
> or she (sorry, I don't know Chinese names) is working on Meego, and I've
> thought that Meego got the policy framework from Maemo. In Maemo the
> routing is handled by module-policy-enforcement (which gets the command
> to enable the bluetooth-hsp routing mode from the policy framework), and
> it works pretty nicely for this kind of use cases.
Interesting, thanks for the info. It's kinda hard to keep up to date
with branches that I don't actively follow :)
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] rewind and underrun issues on start of playback
'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble: > 2011/5/26 Colin Guthrie : >> 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble: >>> I: main.c: This is PulseAudio 0.9.22 >> >> Just as a very small aside, David did some work on "Fighting Rewinds" >> recently. >> >> Just search the stable-queue git log for "Fighting rewinds"... >> >> These may already be included in your build, but if not it's perhaps >> worth grabbing those patches? > > Thank you Colin, let me have a try. Of course it's probably sensible to just run the whole "stable-queue" branch. That's generally what I do in my distro packages... just apply all stable queue patches on top of the official release. A 0.9.23 release will likely go out soon (if I can nail Lennart down!) based on this branch. 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] rewind and underrun issues on start of playback
'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble: > I: main.c: This is PulseAudio 0.9.22 Just as a very small aside, David did some work on "Fighting Rewinds" recently. Just search the stable-queue git log for "Fighting rewinds"... These may already be included in your build, but if not it's perhaps worth grabbing those patches? 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] fix the assumption that volume is always positive
'Twas brillig, and Lu Guanqun at 26/05/11 09:49 did gyre and gimble: > Add a variable to track whether the actual volume is set or not. > Suppose this: > min volume: -126max volume: 0 > then when user wants to set some constant volume to -10, it would fail. Tanu, are you OK with this patch? 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] ask about the assumption of min volume and max volume got from ALSA
Hi,
'Twas brillig, and xing wang at 26/05/11 04:52 did gyre and gimble:
> Would you please give some comments about Guanqun's patch?
> We're working on Pulseaudio and meet some bugs, i think we will run
> faster with community's help.
Absolutely!
To be honest tho', I was hoping Tanu or David would give their takes on
this patch (which they may still do) as they have a better grasp of the
audio control side than I do.
One thing I will say is that PA will use the info from alsa in such a
way as to provide a consistent dB range further up the stack.
We take the alsa-provided 0dB point and mark that as our "Base volume"
this is exposed e.g. in the pavucontrol and gnome-volume-control GUI's
This base volume is meant to indicate the "cleanest" path through the h/w.
This might not be super relevant to the specific issue in question, but
that's a little background on the dB levels exposed by alsa, but I get
the impression the volumes you're talking about are not dB related?
Looking at your patch, it seems logical enough (although for internal
code, I'd use pa_bool_t + TRUE/FALSE values, but that's just a minor
observation), so if Tanu ACKs it, I'd happily merge it.
Cheers
Col
> thanks
> --xingchao
>
> 2011/5/25 Lu Guanqun :
>> Hi,
>>
>> This patch needs a little more love. :)
>> No one cared?
>>
>> On Wed, May 25, 2011 at 02:17:18PM +0800, Lu Guanqun wrote:
>>> Hi list,
>>>
>>> I may not have the background on this issue, but from the code, it seems
>>> the code assumes min_volume and max_volume should be non negative. Is
>>> this the right assumption we should take? What about some drivers
>>> exposes that min_volume is -126 and max_volume is 0? Should we fix the
>>> driver or generalize pulseaudio code to tolerate these issues?
>>>
>>> If we allow min_volume could be less than zero, and how about the below
>>> patch in your point of view? Could you have a review of the below patch?
>>> If that's OK, I can send a standalone patch for it.
>>>
>>> From 1f5c8fa0e80d9fe2e3d56133afa8fe9a5dbe6693 Mon Sep 17 00:00:00 2001
>>> From: Lu Guanqun
>>> Date: Wed, 25 May 2011 14:12:52 +0800
>>> Subject: [PATCH] fix the assumption that volume is always positive
>>>
>>> Add a variable to track whether the actual volume is set or not.
>>> Suppose this:
>>> min volume: -126max volume: 0
>>> then when user wants to set some constant volume to -10, it would fail.
>>>
>>> Signed-off-by: Lu Guanqun
>>> ---
>>> src/modules/alsa/alsa-mixer.c |6 +-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
>>> index 1bd709a..23651b0 100644
>>> --- a/src/modules/alsa/alsa-mixer.c
>>> +++ b/src/modules/alsa/alsa-mixer.c
>>> @@ -1123,6 +1123,7 @@ static int
>>> element_set_constant_volume(pa_alsa_element *e, snd_mixer_t *m) {
>>> snd_mixer_selem_id_t *sid = NULL;
>>> int r = 0;
>>> long volume = -1;
>>> +int volume_set = 0;
>>>
>>> pa_assert(m);
>>> pa_assert(e);
>>> @@ -1136,6 +1137,7 @@ static int
>>> element_set_constant_volume(pa_alsa_element *e, snd_mixer_t *m) {
>>> switch (e->volume_use) {
>>> case PA_ALSA_VOLUME_OFF:
>>> volume = e->min_volume;
>>> +volume_set = 1;
>>> break;
>>>
>>> case PA_ALSA_VOLUME_ZERO:
>>> @@ -1143,18 +1145,20 @@ static int
>>> element_set_constant_volume(pa_alsa_element *e, snd_mixer_t *m) {
>>> long dB = 0;
>>>
>>> volume = decibel_fix_get_step(e->db_fix, &dB, +1);
>>> +volume_set = 1;
>>> }
>>> break;
>>>
>>> case PA_ALSA_VOLUME_CONSTANT:
>>> volume = e->constant_volume;
>>> +volume_set = 1;
>>> break;
>>>
>>> default:
>>> pa_assert_not_reached();
>>> }
>>>
>>> -if (volume >= 0) {
>>> +if (volume_set) {
>>> if (e->direction == PA_ALSA_DIRECTION_OUTPUT)
>>> r = snd_mixer_selem_set_playback_volume_all(me, volume);
>>> else
>>> --
>>> 1.7.2.3
>>>
>>> --
>>> guanqun
>>> ___
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss@mail.0pointer.de
>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>
>> --
>> guanqun
>> ___
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss@mail.0pointer.de
>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>
--
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] DLNA/Airplay Support
Hiya, 'Twas brillig, and Aditya Rajgarhia at 25/05/11 19:34 did gyre and gimble: > I recently bought a DLNA-compliant stereo receiver (the Denon RCD-N7), > and would like to send all audio from my computer to the receiver. This > is feasible in the protocol, since people using Windows Media Player 12 > are able to select the output device (such as a DLNA receiver or > speakers) via a "Play To" option. > > I have been able to have my laptop act as a DLNA server using mediatomb > and make the receiver browse and play particular files from the server. > But what I really want is to stream *all* audio from the laptop. Is this > something that can be done currently? In theory this works, tho' I've not really had massive success with it myself. In paprefs you should see DLNA support (perhaps it's labelled as rygel. It is via rygel that we support exporting the audio of your laptop as DNLA streams. It requires that you manually load module-http-protocol-tcp (pactl load-module module-http-protocol-tcp) and making sure the firewall is open on it's port (4714 or 4715 IIRC, but please check with netstat -ltp :)) Personally I didn't get it working on my PS3 but haven't had a place since some extra patches went in... till give it a bash over the weekend. > If DLNA is not a solution for my needs, would Apple Airplay work? I see > that PulseAudio has a feature for "discovering" Airplay devices on the > network. Has anyone tried using this? My receiver supports Airplay as > well, but I need to pay extra $$$ to download the Airplay firmware so if > PulseAudio doesn't support it yet then there is no point in buying the > firmware. As the author of the Airtunes support in PA I will admit it's still kinda lacking. The timing is all a bit messed up and it really needs some love. Now that we support passthrough, we'll have to have a look at getting MP3 support included too, but that really does require us to tidy up the protocol support first (which is pretty hard). So in short, it's not likely to be a great option but if you can't get the DLNA working, then it might work OK for you. 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] How to debug a "protocol error" message?
'Twas brillig, and Tanu Kaskinen at 25/05/11 21:33 did gyre and gimble: > Sorry for joining the discussion late... I haven't read Pulseaudio mail > since last Thursday. No worries :) > Quinn asked whether it's possible to force Pulseaudio to use an older > protocol version. That's not currently possible, but maybe it would make > sense to add such a feature? I imagine it wouldn't be too hard. I don't > think there are any other reasonably easy solutions. Yeah that would probably be a wise plan. Like you say it shouldn't be too hard. 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] How to change profile of bluetooth headset for different applications?
'Twas brillig, and Lin, Mengdong at 24/05/11 16:18 did gyre and gimble: > The idea of intended profile is awesome! Great thanks for sharing, Col! I'll > try to implement the pseudo module as you suggested. > > I have a quick question: >> Then a separate module (module-intended-profiles?) could take care of >> listening quite generically for streams landing on sink and do the >> following logic ... > > Which event shall I hook for "stream landing on sink", is it > "PA_CORE_HOOK_SINK_INPUT_PUT"? Yeah I think that's the right one I'd normally say the _NEW one, but we need to actually route things first (i.e. assign a sink to the sink-input) and thus the _PUT is likely the right one. Like I said in the last mail however, I suspect there could be problems with changing the profile here due to race conditions of calling a function inside a hook that triggers another hook, but if we're lucky there wont be any other module fiddling about that would conflict with this logic. It should be quite quick to test it all out tho' just to check that all is well :) Good luck and feel free to ask any other questions. You can also pop on IRC if you like :) 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] Why is it still hissing?
'Twas brillig, and David Henningsson at 24/05/11 15:04 did gyre and gimble: > (Btw, based on this analysis, I'm guessing that my former fix fixed the > problem for amd64, but not i386.) This could be correct as when we inspected this error at my house, the server actually doing the output was indeed i386, even if my machine is x86_64... Cheers for hunting this down :D Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to debug a "protocol error" message?
'Twas brillig, and Maarten Bosmans at 24/05/11 08:31 did gyre and gimble: > 2011/5/23 Quinn Plattel : >> Hi, >> >> I am currently having problems with communication between a version 0.9.22 >> pulseaudio client and a version 0.9.15 pulseaudio server. >> Here are the steps to reproduce the error message: >> pulseaudio server side: ssh -X -R 4713:localhost:4713 >> "PULSE_SERVER=localhost:4713 pactl stat" >> >> client reports: >> >> Using shared memory pool with 1024 slots of size 64.0 KiB each, total size >> is 64.0 MiB, maximum usable slot size is 65472 >> Trying to connect to localhost:4713... >> SHM possible: yes >> Protocol version: remote 16, local 16 >> Negotiated SHM: no >> Connection failure: Connection terminated >> - >> >> server reports: >> -- >> protocol error, kicking client >> -- >> >> I have done some testing and a 0.9.15 server has no problems communicating >> with a 0.9.14 client, but >> a 0.9.15 server has this error when communicating with a 0.9.19 or 0.9.22 >> client. >> >> Where do I begin to debug this error? > > The difficulty here is of course that while the server throws an > error, you're looking to fix the client side, because there won't be a > maintainance release of the 0.9.15 series anymore. > > If you can install debug symbols, you can set a breakpoint at > protocol_error(). This will break in command_stat() > (src/pulsecore/protocol-native.c), right after the > !pa_tagstruct_eof(t) check. There you can inspect what kind of > unexpected extra data is in the tagstruct and take it from there. > > Please also try whether other commands work. Yup Maarten's advice is good there. But what is interesting is that our official 0.9.15 version ships with protocol 15, not 16... Your debug suggests the the remote end is protocol 16.. This suggests to me that the extensions in the Maemo version are non-standard and therefore require consultation with their lists. You should check their code to see what commits changed the protocol version to 16. It could be that they just backported the changes from our version 16 shipped in 0.9.16 (which was an API to select client side API detection) or it could be something completely custom. As I'm not familiar with their modifications, I cannot really help. 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] Dealing with the ThinkPad hardware mixer
'Twas brillig, and Andrew Lutomirski at 23/05/11 18:59 did gyre and gimble: > On Mon, May 23, 2011 at 1:50 PM, Colin Guthrie wrote: >> 'Twas brillig, and Andrew Lutomirski at 23/05/11 18:21 did gyre and gimble: >>> What is the kernel supposed to do to get PulseAudio to DTRT? On some, >>> but not (I think) all, models, we can disable hardware mixer control >>> and make all of the buttons act like ordinary buttons, but that will >>> cause the light (if present) to malfunction, and I don't know if all >>> models can do this. So as it stands, PulseAudio would have to >>> understand that the mixer is special and watch for ALSA change >>> notifications. >>> >>> I'm willing to change the thinkpad-acpi driver to make it work better, >>> but I know nothing at all about PulseAudio internals. What should I >>> do? >> >> Can you give some more details? >> >> e.g. does it show up under the same alsa card as the HDA or is it separate? >> >> amixer -c0 (or appropriate number) would be useful to begin with :) > > It's separate. I can send details when I get home, but from memory: > > alsamixer -c1 sees the HDA mixers. > alsamixer -c29 sees the thinkpad-acpi mixer. > > On recent thinkpads with my pending thinkpad-acpi changes, alsamixer > -c29 will update itself when the hardware buttons change the mixer > state. Without my patches, alsamixer won't notice. Ahh, tricky! In an ideal world, it would be super awesome if the alsa user-space lib could configure the additional controls within the same card (in much the same way that it sometimes configures a PCM control for the softvol plugin), thus solving the problem below PA. If that was possible, supporting this would be rather trivial in PA. But if not, I think the solution could be related to some support that is proposed to help a different, but related problem. To give some background on that problem: When you plug a USB device in that is e.g. a headset, but also contains some volume buttons to adjust the vol. Now these buttons appear under /dev/input but in a way that doesn't really tie in to the actual sound card, so when the user presses these buttons, we don't have any way to adjust the correct sound card. At present, pressing such buttons changes the volume of the current default card, not the one it's actually physically connected to (unless it happens to be the default). So, the idea was to attach some kind of "originating device" property via udev to both the sound card and the input device. This would allow us to pair them with each other and thus the desktop environment could ultimately adjust the correct volume when it handles the volume key press events. I suspect a similar thing could be done here... i.e. somehow pair the two controls. That way we can enumerate the controls as a single entity. > The magic hardware mixer is a created by the thinkpad-acpi driver > without any attempt to associate it with any other ALSA device on the > system. I suspect that the driver should be doing something different > (and again, I'm willing to make and submit changes, but I don't know > what it should do to make PulseAudio happy). The changes needed here are rather extensive so I wouldn't expect it to happen overnight sadly. There could be some kind of hacks introduced in the mean time, but I'm not really in a position to guess at this. David and Tanu are probably in a better position, but David is on leave for a couple weeks so likely won't read this for a while The code in PA is quite flexible but it's ultimately rather complex. We have a whole bunch of mixer profiles that ultimately work out what the card is capable of. It's quite focused on applying ot a single control interface just now, and I can't think of a clean way of the top of my head to extend that, but then I don't know that code, so this is, in itself, not overly surprising :) Please do post the additional mixer details when you have them. -- 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] Dealing with the ThinkPad hardware mixer
'Twas brillig, and Andrew Lutomirski at 23/05/11 18:21 did gyre and gimble: > What is the kernel supposed to do to get PulseAudio to DTRT? On some, > but not (I think) all, models, we can disable hardware mixer control > and make all of the buttons act like ordinary buttons, but that will > cause the light (if present) to malfunction, and I don't know if all > models can do this. So as it stands, PulseAudio would have to > understand that the mixer is special and watch for ALSA change > notifications. > > I'm willing to change the thinkpad-acpi driver to make it work better, > but I know nothing at all about PulseAudio internals. What should I > do? Can you give some more details? e.g. does it show up under the same alsa card as the HDA or is it separate? amixer -c0 (or appropriate number) would be useful to begin with :) Thanks Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to change profile of bluetooth headset for different applications?
e is not needed. > How can the Bluetooth device module know whether it’s the default device > for an application when this application’s input stream is PUT? Good question! I'm not 100% sure, but I think the approach I outlined above (caveats with races not withstanding) could be the short term solution. We were recently talking about routing to sinks+ports in a discussion on this ML (jack detection related from a week or so back). Ports are sink-level config options and in many ways it may make sense to change from "card profiles" to "sink ports" for the HSP<->A2DP change (although the fact that the sample spec etc. may change may make this a non-option - I don't know enough about BT to say at this stage). We decided that we probably wanted the routing to work in such a way that entries in the priority list would be keyed by the sink+port. This would allow us to use "is jack plugged in" in our routing decisions. e.g. a user may want to use in order of priority 1) his headphones plugged into internal jack 2) USB speakers 3) Internal speakers. Essentially 1 & 3 are the same sink but with different "ports" active. In this case, if it were possible to put the HSP vs A2DP choice into sink ports, then the following may be present in the "phone" priority list: 1. BT+HSP 2. BT+A2DP 3. Speakers If no bluetooth device is present, it'll use the speakers for a "phone" stream. Then you turn you bt headset on and (for arguments sake) it defaults to A2DP. The fact the device has shown up triggers a "reroute" where the routing priority lists are applied to running streams. Thus the phone call is moved to the BT+A2DP sink. Now, the pseudo module I outlined above kicks in (but rather than module-intended-profiles which acts on a card proplist metadata to change a card profile, it becomes module-intended-ports and acts on the sink proplist metadata to change a sink port). This module sees a phone stream on the sink that an "intended port" for phone streams and thus it changes the port for us. This cases BT+A2DP to disappear but BT+HSP to appear. Again a reroute is triggered and now the stream is moved to the BT+HSP sink. So with this approach everything works nicely the question is, is it possible? In the short term, I think the card profile changing module is the way to go! HTHs 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] Strange parsing module args?
'Twas brillig, and mar...@saepia.net at 21/05/11 16:14 did gyre and gimble: > why following command does not work > > load-module module-null-sink sink_description="tuned\ patchbay:\ TCP\ > source\ xxx",sink_name=tuned.patchbay.source.xxx > > > while this one works: > > load-module module-null-sink > sink_name=tuned.patchbay.source.xxx,sink_description="tuned\ > patchbay:\ TCP\ source\ xxx" > > > Why argument order makes difference? Is it correct behaviour or a bug? Neither are correct! The arguments should be separated by spaces, not commas and the argument for "sink_description" is actually "description" (although even this is deprecated as you should now use the more generic "sink_properties" argument with a device.description= entry. In the second example above, by using a comma, you're actually just giving your sink a crazy name without any description at all! e.g. both: load-module module-null-sink description="tuned\ patchbay:\ TCP\ source\ xxx" sink_name=tuned.patchbay.source.xxx and load-module module-null-sink sink_name=tuned.patchbay.source.xxx description="tuned\ patchbay:\ TCP\ source\ xxx" both work fine. But a better way of doing it would be: pactl load-module module-null-sink sink_name=tuned.patchbay.source.xxx sink_properties=\"device.description=\\\"tuned patchbay: TCP source xxx\\\"\" (note that as I passed this ivia the command line, I had to double escape the escaping!) It would be slightly less nasty looking if it was in the startup script (i.e. default.pa or system.pa) HTHs 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] How to redirect pulse audio through ssh?
'Twas brillig, and Quinn Plattel at 23/05/11 05:52 did gyre and gimble: > HI. > > Last post on this thread, then I will start a new one. > I managed to cut down the delay considerably by simplifying the commands: > > local sound server: ssh -L 5901:localhost 5901 -L 1234:localhost:1234 > *parec | nc -l 1234" > local sound server: nc localhost 1234 | pacat > > The advantage with this is that the volume can be controlled manually > with the local sound server's volume control and the delay is cut down > to 3-5 seconds. The commands and procedure I outlined before is working fine and is free from bizarre work arounds. I'm not sure if the protocol error you are getting is coming form a bug in the client side or the server side, but either way it can be easily fixed if it's debugged appropriately. The lack of a cookie can be solved in several ways (e.g. by copying the ~/.pulse_cookie file between machines, or by setting up anonymous authentication when loading the TCP protocol module). I don't think your workaround (while creative) is the right way to go. Far a start parec|pacat has no dynamic sample rate adjustments to compensate for different clocks. Also with the parec command it seems you are connecting to to the remote PA daemon and recording from a monitor source (assuming no real source exists on the machine, the monitor source would be the default) so as to capture the sound which you then play back via pacat on the local system. If that's the case then you're already talking to the wrong PA daemon. As I said in my previous mail any client that runs on the remote system should connect *directly* (via SSH tunnel) to the remote PA. I'm sure it wouldn't take too long to work out the incompatibilities between the two protocol versions, but perhaps the one in Maemo has some kind of customisation applied on top that makes it generally incompatible? In general the protocol is backwards compatible and while I'd have to look, I'm not aware of any specific incompatibilities between 0.9.21 and 0.9.15 But if you cannot work out the protocol error here, I guess you're work around is the easiest option :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [ANNOUNCE] Mailing Lists Move
Hello, Over the past couple days I've been configuring and setting up the three PulseAudio mailing lists on it's new home: http://lists.freedesktop.org/ Your subscriptions will be automatically moved across, but some settings, such as "No Mail", "Digest" etc, will sadly not be preserved (I'm sure there is a way to do this, but I can't find and easy way via web interfaces and, quite frankly, I've got more to worry about that a couple of settings tweaks for a minority of users!) As things stand, I've migrated across the "commits" mailing list and will do the bugs mailing list shortly. The list archive will also be imported in due course. With regards to gmane integration, it will receive messages quite happily and (I hope) it will work fine when some mail aliases are configured too, but there may be a problem with this so please keep it in mind over the next couple days. I'll send another message once everything is migrated and also when the new list is fully active so those people on digests and with nomail will be informed of the change. 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] Call for PA related blog feeds
Hello everyone! I'm looking for PA related blog feeds please! If you write a blog and occasionally mention PA and want to be included in a "Planet PulseAudio" aggregated site, then please send me your Feed URLs The feeds should be PA-specific. In the case of myself and others, we tag our PA posts with a certain tag and then the feed can be generated from all the posts with that tag. Your feed URL should work in a similar way. Please either send them to me directly or just post it on this list. I've already got myself (obviously) Arun and Kurt on my list. Lennart, I'm not sure you're blog has any tags (if they are they are not public) so perhaps you have some suggestions here (or maybe it's a hidden feature). I've got everything already setup on my machine, but this is not it's real home, so I won't publish the URL just yet :) 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] How to redirect pulse audio through ssh?
Hi, I think you're maybe getting a little confused by client and server in terms of how things work here (perhaps not, as I've not thoroughly read all the many posts in this thread). As I know how to do what you want to do, I'll just write the instructions here: 1. Start of on the machine you want to hear the sound on. This will be your local terminal. It's the "server" in this case as it's running the PulseAudio server. You do not need to run a PulseAudio server on the other machine, just use the PulseAudio client library for audio (either directly or via alsa-pulse plugin). 2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure this has some output. If it does not then chances are the "start-pulseaudio-x11" script was not run at login (or you have restarted your PA server after logging in). Try just running "start-pulseaudio-x11" and see if that fixes it. 3. Ensure that the tcp native protocol module is loaded. "pacmd list-modules | grep module-native-protocol-tcp" If it is not loaded, then simply type: "pactl load-module module-native-protocol-tcp" 4. SSH to your other machine: ssh -X -R4713:localhost:4713 OTHERMACHINE If you get a warning: Warning: remote port forwarding failed for listen port 4713 then chances are there is a PA daemon running there already, or you've SSH'ed twice. If the former, just change the *first* instance of 4713 to a random number of your choice (>1024). 5. On this remote machine, check your cookie is available via the xprop command show in step 2. If X11 forwarding is working properly, it should show up fine. 6. Set the PULSE_SERVER variable to the forwarded tunnel port. export PULSE_SERVER=localhost:4713 (or the port number you picked in step 4 if different) 7. Confirm it's all working: PULSE_LOG=99 pactl stat Done!! So in this setup, the cookie used for authentication is forwarded automatically via piggy backing on to X11 connections but as you cannot connect directly to the machine we've had to override the PULSE_SERVER variable to go over the SSH tunnel. Below is the output from my session where I run these exact commands (note the host name in the pactl stat at the end). HTHs Col [colin@jimmy ~]$ hostname jimmy [colin@jimmy ~]$ xprop -root | grep PULSE_COOKIE PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9.." [colin@jimmy ~]$ pacmd list-modules | grep module-native-protocol-tcp name: [colin@jimmy ~]$ ssh -X -R :localhost:4713 mediacentre Last login: Sat May 21 18:51:40 2011 from jimmy.local [media@(Media)centre ~]$ xprop -root | grep PULSE_COOKIE PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9.." [media@(Media)centre ~]$ export PULSE_SERVER=localhost: [media@(Media)centre ~]$ PULSE_LOG=99 pactl stat Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496 Trying to connect to localhost:... SHM possible: no Protocol version: remote 21, local 16 Negotiated SHM: no Currently in use: 2 blocks containing 149.9 KiB bytes total. Allocated during whole lifetime: 1220055 blocks containing 1.6 GiB bytes total. Sample cache size: 86.0 KiB User name: colin Host Name: jimmy Server Name: pulseaudio Server Version: 1.0.0-0.354.1.csg1 Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: alsa_output.pci-_00_1b.0.analog-stereo Default Source: alsa_input.pci-_00_1b.0.analog-stereo Cookie: d7756be2 [media@(Media)centre ~]$ -- 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] How to redirect pulse audio through ssh?
Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: > I am currently trying to attempt to redirect pulse audio sound from a > server to a client through ssh. I am bit unclear on what the correct > way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from "xprop -root | grep PULSE". Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [ANNOUNCE] Git repository move.
Hi Guys, As you may know we're generally (slowly) moving hosting of the PA Project across to the infrastructure provided by freedesktop.org. As the first step in this process, we'll be moving our git hosting. So please can you run the following commands on your system if you have any git checkouts. This command only needs to be run once on your machine to configure shortcuts for the fdo git hosting infrastructure: git config --global url.git://anongit.freedesktop.org/git/.insteadof fdo: git config --global url.ssh://git.freedesktop.org/git/.pushInsteadof fdo: Then on any PA clones you have simply do: git config remote.origin.url fdo:pulseaudio/pulseaudio That's all that is needed! If you want a gitweb view (or rather a cgit which kicks gitwebs ass IMO): http://cgit.freedesktop.org/pulseaudio/pulseaudio/ Many thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Source Output Volumes
'Twas brillig, and Maarten Bosmans at 20/05/11 10:23 did gyre and gimble: >> > With flat volumes, adding per-stream volumes to capture streams makes >> > sense. > With these changes, would it still be possible to record audio without > software gain? As it is now, I can record from a source that has its > volume set to 100% and be confident that I'm getting the signal direct > from the soundcard. > Is that still the case with the default source output volume? Yeah, that should still be the case. If you set the volume to of your stream to 100%, even if some other stream is recording at 50%, the h/w volume should be set to 100% Of course this is all rather arbitrary, as on my h/w the gain is 0dB when I set the volume to 0 at 100% it's +22.5dB, so to say direct from the sound card at 100% is a little strange it's getting +22.5dB :) I guess the problem would come when recording two things at once. If you set one to 100% (thus +22.5dB on my system) and one to the base volume of the source it's attached to (thus ALSA's 0dB*), then the one that expects to be recording at 0dB will actually get a signal that has gone up to +22.5dB and then come back down in software to 0dB. This isn't ideal, but then it's as non-ideal as it is currently and the use case for recording two streams at the same time is rather minimal anyway, so I don't think in all practicality, this is a big issue. Of course if you don't use flat volumes and only use per-stream recording volumes in your app, then the difference between the source volume and the stream volume does come into play AFAIUI. But then if you take the time to disable flat volumes, that's presumably a consequence you can live with. Col * I have one USB mic that reports it's range as +20dB to +50dB in alsa, so the base volume for it is actually significantly below the ALSA 0 point on the kcontrol! -- 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] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 19/05/11 19:04 did gyre and gimble: > I'm not trying to make it all just work atm, only provide > a basis to continue working on and advance the discussion. Awesome! My previous mail was my polite way of saying "it may not get committed just yet in it's current form" but your reply tells me you fully appreciate that. I'll let discussions continue in other branches of this thread. 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] Source Output Volumes
Hello, As some of you know I've been working on restoring a little more symmetry to our API to allow the adjustment of source output (capture stream) volumes. In the past, when stream volumes were added to sink inputs, it was thought that this feature wouldn't be overly useful for capture streams and while this argument still holds true, there is one feature that has since been added to PA that would make it useful - flat volumes. Flat volumes allow for multiple streams to be connected to the same device and when they differ in stream volume, the maximum one is chosen and the h/w is set to that, with the difference in volume between the streams applied in software. This in theory allows for optimum power efficiency where the software stays out of the loop whenever possible. With flat volumes, adding per-stream volumes to capture streams makes sense. It does also simplify client code when they want to adjust their own volumes, they don't have to implement their own asymmetry to deal with ours. So I am proud to announce my work to try and achieve this. There are no doubt still bugs, so a thorough review is very much appreciated. I will not post patches to the list (unless screamed for) as some of them are necessarily rather large (+400 and +2k lines in the biggest patches). Most of the code is mirrored from the sink or sink input side. There is a lot of scope to cut down on code duplication but for the purposes of getting this out there I'll leave that for after the next release. In some cases, applying the patch and comparing e.g. sink.c with source.c is a better way of reviewing the changes (while there are still several differences it isn't too hard to compare them). I originally added support for synchronised streams for recording but then realised that this makes little sense practically and removed it again. I did the removal in a separate commit as it may be easier to compare the sink vs. source files before this patch to cut down on asymmetry) Known niggles; There are still some strange things with volumes. The flat volume stuff doesn't seem to work perfectly as when adjusting a recording stream volume down from NORM, the h/w volume does not drop... only when the hardware volume has been moved down to 0 and back to NORM does flat volume stuff work seem to work properly. I think there are still a few niggles with volume setting generally (for outputs too) as I still have a problem reported earlier that the initial volume of things is disconnected to the h/w state and while PA thinks it's got 100% it's actually not... I still need to look at that properly. So without further ado, here is the branch for review: http://colin.guthr.ie/git/pulseaudio/log/?h=master-source-volume git://colin.guthr.ie/pulseaudio (master-source-volume branch) For convenience of testing you can also use this patch to pavucontrol: http://colin.guthr.ie/git/pavucontrol/log/?h=master-source-volumes Have fun! 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] Jack detection
ternal Audio Analog Stereo (Speakers) Internal Audio Digital Stereo Network Tunnel to Foobar Bluetooth Headset This would mean that if I do not have the jack plugged in, but I do have my USB speakers, then the sound would come out of the USB device, but when I plug in a 3.5mm jack to my built in speaker, the audio would switch to that. The above does have some fairly significant advantages (the above setup paints the use case quite clearly IMO). Of course if the priority lists are not exposed under some DEs (i.e. Gnome) then auto management of the lists is more problematic... i.e. if we move a stream to a new device, if the prio lists are not exposed, this will typically result internally in us moving that device to the top of the list. But if our lists are internally using device+port, then should the auto-management also move all entries of that device to the top (preserving their current order of ports) or just the single device+port that is currently in use? I suspect the former is more logical as this is likely how the GUI will be presented (i.e. it will be "Move to Internal Audio Analog Stereo" rather than "Move to Internal Audio Analog Stereo (Headphones)") but it does mean the above priority list would be impossible to configure under such internal auto-management. Such is the tradeoff perhaps? The only problem with combining sink+port into one "pseudo device" for display in GUIs is it kinda breaks the whole "show all sinks from a profile and allow them to be activated" GUI approach. None of these ideas are set in stone and I'm not really a GUI expert of anything, so this can all be accommodated in the long run... this is likely more of a brain dump on how this is all exposed to higher up the stack :) Hope it's vaguely useful and understandable (it's often quite hard to describe what you visualise quite clearly in your head!) 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] How to find the latest created bluetooth sink/source via event hook?
'Twas brillig, and Lin, Mengdong at 19/05/11 03:09 did gyre and gimble: > Great thanks for your advice, Col! > >> Please note that there already exists a module called >> module-switch-on-connect which does this task, but for all new sinks, >> not just BT sinks. ... > > I found "module-switch-on-connect.c" is not in 0.9.22 tar ball but in git. > When will this module be released? > My work is still based on 0.9.22 and need upgrade to use this module. Indeed it's not in 0.9.22 It will be trivial to back port, I think it's only one git commit. The Makefile.am may need a little tweaking but it should be very easy. So even if it's not in the version you need to use, I'd backport it then improve it as you need and we can still ultimately take those improvement patches with little trouble :) We're hoping to get git master out pretty soon, within the next month or so, but depends on various stabilising efforts and peoples time :) >> Just so you know, I will am intending on shaking up the routing system >> in PA after v1 is released which will hopefully make this kind of thing >> easier to implement and manage. ... but essentially the routing will be >> based on priority lists of >> devices rather than just setting a single device to use. > > It sounds great! Could you share more information on this new design, maybe > in a new thread? Arun already replied with the link that I forgot to put in the first mail... :p -- 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] Debugging Pulse Audio
Hiya 'Twas brillig, and Himanshu Chug at 18/05/11 13:40 did gyre and gimble: > I am trying to debug pulse audio v0.9.21 code (on Ubuntu desktop) by > running some test playback .pcm stream. > I guess to check the code logs I need to start the pulse audio daemon in > debug mode. > > 1. How can I Stop the existing PA daemon? when I try to KILL the daemon > it automatically started again (may be due to some configuration.?) Typically you can: echo "autospawn=no" >> ~/.pulse/client.conf to prevent autospawning. (man pulse-client.conf) PA will likely still start at login to X11 due to XDG scripts triggered at login, but it will not autospawn and thus some apps that start during the early login may actually flip over to a non-PA mode due to this change, so I'd recommend reverting the change when you are done or accepting the consequences (I turn off autospawn generally and accept that some login items might misbehave a bit) > 2. How to again Start the daemon in Debug mode? Generally I run it manually: pulseaudio -v > 3. How and where to check for PA code logs ? You can configure the log target and level in daemon.conf (man pulse-daemon.conf) or just use the console output from the above command. HTHs 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] Receiving RTP streams with pulseaudio
'Twas brillig, and Rémi Denis-Courmont at 18/05/11 07:37 did gyre and
gimble:
> On Tue, 17 May 2011 21:51:35 +0200, Michael Trunner
> wrote:
>> I'm trying to setup Pulseaudio to receive RTP/Multicast steams. Sender
>> should be vlc, (and receiver should be pulseaudio). I activated
>> module-rtp-recv (and module-rtp-send) with papref, but I can't get it
>> work. Can some one explain me what I have to do? Or how to debug it.
>
> First you need to make sure that VLC uses an RTP payload format that
> PulseAudio understands, typically L16/44100/2 (signed big endian 16-bits
> stereo at 44100 Hz). By default, VLC will not decode the audio. Also make
> sure SAP is enabled.
>
> For example:
> # IP=224.0.0.42
> # vlc --sout-keep --no-sout-video --no-sout-spu \
> --sout
> "#transcode{acodec=s16b,samplerate=44100}:gather:rtp{sap,dst=$IP}"
>
> Then you need to configure PulseAudio to use the standard SAP address as
> specified in IETF RFC2974 §3, corresponding to the multicast scope that VLC
> is configured to use, in particular:
> - 224.2.127.254 (SAP.MCAST.NET) for global IPv4,
> - ff0e::2:7ffe for global IPv6,
> - 224.0.0.255 for link-local IPv4,
> - ff02::2:7ffe for link-local IPv6.
Many thanks for the info Rémi :)
> By default, PulseAudio uses a proprietary non-standard SAP group, namely
> 224.0.0.56. This cannot interoperate with VLC.
Interesting. I see from the history:
commit e1887b552ceb324f70732c85c7458119e03718b7
Author: Lennart Poettering
Date: Sun Apr 16 11:13:20 2006 +
change default mcast address once again, to make sure our traffic
doesn't leave the network by default
Previously the address was 224.0.1.3
The change before that is:
commit c999fe40b841b035c7d0c873b4a4875e12e9c9a4
Author: Lennart Poettering
Date: Sun Apr 16 09:15:51 2006 +
* deal properly with underruns, overflows and packet losses
* change default mcast address
* detect RTP loops
Which had the address as 224.0.1.2. This was the address used when the
module was committed.
This default can be overridden in the module-rtp-recv module with the
sap_address= argument. And with the module-rtp-send module with the
destination= argument.
Hope that helps.
If you have any recommendations for the defaults, please feel free to
suggest them, but I guess the intention was to keep the traffic in house
by default. We should likely expose via paprefs the ability to choose a
public mutlicast group or something. WDYT?
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] my paulseaudio is not running as daemon
[Please try to avoid top-posting. It's considered bad netiquitte on most mailing lists as it disrupts the flow of reading] > 'Twas brillig, and Fu, Zhen at 18/05/11 08:05 did gyre and gimble: >> 'Twas brillig, and Fu, Zhen at 18/05/11 07:50 did gyre and gimble: >>> I need developing PA client App,so I download pulseaudio-0.9.22 and >>> run “./configure,make,make install”.After install finished,I run >>> “pacmd”,but display “No pulseaudio daemon running,or not running as >>> session daemon”.Then,I run “ps aux | grep pulse”,but display >>> “pulseaudio –start”. >> >> Are you running this as root or a regular user. >> >> What does (as a regular user) pulseaudio - say (I suspect daemon >> already running or pid file already exists or similar)? >> >> Are you using a distro? If so what version does your distro include >> and did you overwrite you distro version with your self build version >> or is it now installed into /usr/local instead? >> >> Also, I would suggest the stable-queue git branch rather than 0.9.22 >> as this contains several bugfixes on top of 0.9.22. > I running this a regular user.I download pulseaudio-0.9.22 in > www.pulseaudio.org, it is now install /usr/local/. OK, so is the version that is running the distro provided one or your new one? Chances are it's your distro version and your self compiled version of PA are in some way conflicting. Can I ask specifically why you need to build your own version of PA and not use your distro version? You said originally you are developing a client application for PA. Is this the case or are you hacking on PA code itself? If the latter then you should really use git so that you can track your changes. If the former (you are just developing a PA client app), then just install your distros development package for PA and you should be good to go, avoiding any hassle. If you really do want to run PA and don't want to over write your distro version, I wrote a guide some time ago about running PA from git: http://colin.guthr.ie/2010/09/compiling-and-running-pulseaudio-from-git/ You also did not supply the pulseaudio - output that would have aided debugging, but hopefully we can short circuit all that if you are just developing a client app as you don't need to build your own PA for that :) 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] build error
'Twas brillig, and Colin Guthrie at 18/05/11 07:53 did gyre and gimble: > Hiya, > > 'Twas brillig, and Himanshu Chug at 18/05/11 07:30 did gyre and gimble: >> This is first mail to the list, Hello to evreyone in the list, > > Hello, welcome to the list :) > >> I am new to pulseaudio and I am trying to build the pulseaudio using >> make and get the following build errors: > > I don't personally know much about ARM stuff, but it would help if you > share which version of PA you are building. e.g. Is it v0.9.22 or the > git master or stable-queue branches? > > That info will be useful to people who can (hopefully!) help more than me :) Ahh well, it seem Arun is learned enough to spot the problem without this info, so you can ignore me :D 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] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 18/05/11 07:22 did gyre and gimble: > > On May 17, 2011, at 8:56 AM, Lu Guanqun wrote: > >> On Thu, May 12, 2011 at 02:56:04AM +0800, Jorge Eduardo Candelaria wrote: >>> Ok, I'll copy the jack code we have into module-alsa-card. This will allow >>> for simple jack removal/insertion events to be propagated to pulseaudio. We >>> won't be able to do the complicated stuff mentioned above, but should at >>> least be able to do simple speaker/headphone switching. >> >> Hi Jorge, >> >> I'm interested in your jack detection code, when do you decide to send >> it out? :-) > > Don't worry, I haven't forgotten about it :). I plan to send the new patches > tomorrow > if all goes well with testing. Have you spoken with David about this off-list by any chance? As I mentioned previously, we have quite specific needs for jack detection for it to be accepted so I hope further discussions have happened or that you have managed to be super awesome and make it all "just work" as we want it, otherwise more tweaks will be ultimately be needed :) 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] my paulseaudio is not running as daemon
'Twas brillig, and Fu, Zhen at 18/05/11 07:50 did gyre and gimble: > I need developing PA client App,so I download pulseaudio-0.9.22 and run > “./configure,make,make install”.After install finished,I run “pacmd”,but > display “No pulseaudio daemon running,or not running as session > daemon”.Then,I run “ps aux | grep pulse”,but display “pulseaudio –start”. Are you running this as root or a regular user. What does (as a regular user) pulseaudio - say (I suspect daemon already running or pid file already exists or similar)? Are you using a distro? If so what version does your distro include and did you overwrite you distro version with your self build version or is it now installed into /usr/local instead? Also, I would suggest the stable-queue git branch rather than 0.9.22 as this contains several bugfixes on top of 0.9.22. 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] build error
Hiya, 'Twas brillig, and Himanshu Chug at 18/05/11 07:30 did gyre and gimble: > This is first mail to the list, Hello to evreyone in the list, Hello, welcome to the list :) > I am new to pulseaudio and I am trying to build the pulseaudio using > make and get the following build errors: I don't personally know much about ARM stuff, but it would help if you share which version of PA you are building. e.g. Is it v0.9.22 or the git master or stable-queue branches? That info will be useful to people who can (hopefully!) help more than me :) 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] How to find the latest created bluetooth sink/source via event hook?
Hi, 'Twas brillig, and Lin, Mengdong at 18/05/11 04:43 did gyre and gimble: > I’m developing an routing module to automatically set a new created > Bluetooth sink as the default sink when a Bluetooth headset is connected. Please note that there already exists a module called module-switch-on-connect which does this task, but for all new sinks, not just BT sinks. I suspect it would be trivial to modify it to accept arguments which control things (e.g. device_types="all|bluetooth|usb|network" - or a combination of those i.e. device_types="bluetooth,usb") rather than create a whole new module. If you want your work upstreamed, I would personally take this approach as I'd rather not get too much duplication of code in different modules. > So I need to get the new BT sink when it’s created. Just so you know, I will am intending on shaking up the routing system in PA after v1 is released which will hopefully make this kind of thing easier to implement and manage. Feel free to ask if you want more details, but essentially the routing will be based on priority lists of devices rather than just setting a single device to use. > But when I hook event “ PA_CORE_HOOK_SINK_NEW”, I found that the sink > pointer for the callback function is **not** the real sink pointer value. Correct. This hook is fired before the sink is created to allow you to modify critical details about the sink before it is created. If you want a hook that informs you *after* the sink is created, then you can use PA_CORE_HOOK_SINK_PUT as shown in module-switch-on-connect.c code. > So could anyone share some hint on how to find the new created > sink/source? Shall I iterate the core’s sink/source list and compare > pointers in sink/source state change callback function? I suspect the *_PUT hook is what you want :) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.
'Twas brillig, and Colin Guthrie at 17/05/11 12:13 did gyre and gimble: > 'Twas brillig, and Tanu Kaskinen at 17/05/11 10:37 did gyre and gimble: >> On Mon, 2011-05-16 at 21:22 +0100, Colin Guthrie wrote: >>> OK, here is the debug output from my run using this volume approach >>> >>> As you can see there are several points where the message: >>> >>> "Written HW volume did not match with the request" is shown. This is >>> shown quite clearly when writing the volumes to h/w >>> >>> I suspect this problem arrises due to the use of pa_cvolume_divide() >>> which is based around PA_VOLUME_NORM, when the second argument (the >>> software volume) is > PA_VOLUME_NORM. >>> >>> Any thoughts on this are welcome. >> >> I'll quote the log: >> >> D: protocol-native.c: Client pavucontrol changes volume of source >> alsa_input.pci-_00_1b.0.analog-stereo. >> D: alsa-source.c: Requested volume: 0: 45% 1: 45% >> D: alsa-source.c:in dB: 0: -20.71 dB 1: -20.71 dB >> D: alsa-source.c: Got hardware volume: 0: 45% 1: 45% >> D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB >> D: alsa-source.c: Calculated software volume: 0: 101% 1: 101% >> (accurate-enough=no) >> D: alsa-source.c: in dB: 0: 0.29 dB 1: 0.29 dB >> D: source.c: Volume going up to 29273 at 270475970821 >> D: source.c: Volume change to 29273 at 270475970821 was written 34 usec late >> D: alsa-source.c: Written HW volume did not match with the request: 0: 45% >> 1: 45% (request) != 0: 42% 1: 42% >> D: alsa-source.c:in dB: 0: >> -21.00 dB 1: -21.00 dB (request) != 0: -22.50 dB 1: -22.50 dB >> >> Looking at the last line, the requested volume seems to hit exactly the >> right step (-21.00dB), but for some reason Alsa decides to choose >> something else. I'm pretty sure that this happens because of rounding >> errors. In the first phase we ask Alsa what dB value we should set, and >> it returns -21.00 dB. The value is given as a long int, but we convert >> that to pa_cvolume. Then when we set the volume, we convert the >> pa_cvolume value back to a long integer. At this point I believe it gets >> converted to -2101. This is not visible in the debug message for some >> reason - the rounding algorithm must be different from what was used >> with the pa_cvolume -> long conversion. >> >> Here's a patch that should fix the problem: >> >> http://meego.gitorious.org/maemo-multimedia/pulseaudio/commit/a88c2b1d9f8c2088a430a257470a70efeaaf4b34 > > Thanks, I'll test this patch and see if it helps with my test case. > > Assuming that it does, is this something we should really push to alsa > lib? When I first encountered the problem I did start hacking away at > alsa lib looking for the problem. > > Perhaps a new direction argument -2 and +2 for "nearest below bias" and > "nearest above bias" respectively? (the bias only coming into play when > there you are exactly inbetween two possible values). Just to report that a modified version of that patch does indeed fix the problem for me. What do you think overall? Should we try and hunt down the problems with the conversion or should this patch be included? 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] volume ramping
'Twas brillig, and Baek Chang at 17/05/11 18:13 did gyre and gimble: > Oh great, so it will be merged back into a branch as a new feature. Is > there any place to push patches I've made against it somewhere, or > should i just wait until its merged back in? There isn't a feature branch for this yet as I'm not sure Lennart was really happy with the approach he had (I can't remember the details, either he's not happy with the approach or he didn't have time to properly tidy it up) - either way there is no where just now to apply patches on top, but we could likely introduce a feature branch for this. That said, it's likely going to be quite hard to bring the feature back with subsequent changes in volume code in the mean time (dealing with flat volumes is tricky to say the least!). But obviously we don't want to loose your work so perhaps Arun or even Lennart can make some suggestions in this regard? 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] Assertion '(size_t) decoded == a2dp->frame_length' failed at modules/bluetooth/module-bluetooth-device
'Twas brillig, and h.pa...@accenture.com at 17/05/11 10:53 did gyre and gimble: > Please let me know why I am getting the error" E: bluetooth-util.c: Error > from RegisterEndpoint reply: org.freedesktop.DBus.Error.UnknownMethod " Can't tell you off the top of my head. Perhaps it requires interaction with a newer bluez version or perhaps there is just some problem with your dbus support and the user you are using? As you are running in system mode, you may also have to make some tweaks relating to bluetooth permissions. e.g. see here: http://pulseaudio.org/ticket/898#comment:9 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: When setting hw volume, round always up with playback and always down with capture.
'Twas brillig, and Tanu Kaskinen at 17/05/11 10:37 did gyre and gimble: > On Mon, 2011-05-16 at 21:22 +0100, Colin Guthrie wrote: >> OK, here is the debug output from my run using this volume approach >> >> As you can see there are several points where the message: >> >> "Written HW volume did not match with the request" is shown. This is >> shown quite clearly when writing the volumes to h/w >> >> I suspect this problem arrises due to the use of pa_cvolume_divide() >> which is based around PA_VOLUME_NORM, when the second argument (the >> software volume) is > PA_VOLUME_NORM. >> >> Any thoughts on this are welcome. > > I'll quote the log: > > D: protocol-native.c: Client pavucontrol changes volume of source > alsa_input.pci-_00_1b.0.analog-stereo. > D: alsa-source.c: Requested volume: 0: 45% 1: 45% > D: alsa-source.c:in dB: 0: -20.71 dB 1: -20.71 dB > D: alsa-source.c: Got hardware volume: 0: 45% 1: 45% > D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB > D: alsa-source.c: Calculated software volume: 0: 101% 1: 101% > (accurate-enough=no) > D: alsa-source.c: in dB: 0: 0.29 dB 1: 0.29 dB > D: source.c: Volume going up to 29273 at 270475970821 > D: source.c: Volume change to 29273 at 270475970821 was written 34 usec late > D: alsa-source.c: Written HW volume did not match with the request: 0: 45% > 1: 45% (request) != 0: 42% 1: 42% > D: alsa-source.c:in dB: 0: -21.00 > dB 1: -21.00 dB (request) != 0: -22.50 dB 1: -22.50 dB > > Looking at the last line, the requested volume seems to hit exactly the > right step (-21.00dB), but for some reason Alsa decides to choose > something else. I'm pretty sure that this happens because of rounding > errors. In the first phase we ask Alsa what dB value we should set, and > it returns -21.00 dB. The value is given as a long int, but we convert > that to pa_cvolume. Then when we set the volume, we convert the > pa_cvolume value back to a long integer. At this point I believe it gets > converted to -2101. This is not visible in the debug message for some > reason - the rounding algorithm must be different from what was used > with the pa_cvolume -> long conversion. > > Here's a patch that should fix the problem: > > http://meego.gitorious.org/maemo-multimedia/pulseaudio/commit/a88c2b1d9f8c2088a430a257470a70efeaaf4b34 Thanks, I'll test this patch and see if it helps with my test case. Assuming that it does, is this something we should really push to alsa lib? When I first encountered the problem I did start hacking away at alsa lib looking for the problem. Perhaps a new direction argument -2 and +2 for "nearest below bias" and "nearest above bias" respectively? (the bias only coming into play when there you are exactly inbetween two possible values). 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] [PACKAGERS] New dep
Hi, I've just pushed Arun's (mostly, Pierre-Louis also had a hand!) passthrough work to master. This carries with it a new dependency: json-c We may yet remove this and write our own parser for the simple subset of JSON formatting we use but there may ultimately be other reasons to keep this longer term. But in the interests of simplicity, I'd certainly not be against any native implementation patches that came along provided they were simple and clean. Please test these changes. I'm sure Arun will post more details and test requests in due course. 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] multiseat and PulseAudio?
'Twas brillig, and Tomasz Chmielewski at 16/05/11 10:49 did gyre and gimble: > On 16.05.2011 11:37, Colin Guthrie wrote: > >> Well in this evironment, I'd say that if you only have one card to be >> shared between the seats, then system wide mode is likely the right >> option. >> >> It's not nice generally because: >> 2. One user can spy on the other user monitor their VOIP streams etc. > > Since all users hear the same audio from loudspeakers, it's not a > concern :) Indeed. One man's "problem" is another man's "feature". :p >> And we don't test it particularly heavily, but all in all it should work >> fine (assuming you write your own init script and/or your distro does >> that for you). > > Unfortunately, it does not work fine, and was a reason why I'm > investigating running PulseAudio per-user. > > When I run it in system mode, it crashes (or exits? not sure). It's not > something what happens very often - once every 3 days perhaps. But > annoying (no music anymore, normal user can't start PA in system mode > etc.). > Since the documentation said I'm not likely to get any help when asking > for system mode issues, I though I'm really doing something wrong and I > should use it per-user. Ahh, we're probably a little too forceful there I guess. It's generally to discourage people from the wrong path as there are not that many cases where it makes sense. In your case it does make sense. With regards to bugs, we'll obviously take a look at any problem, especially as one that is triggered in the system-wide case may be triggered in the per-user case too but under less obvious circumstances (or masked by the fact that a typical per-user setup with autospawn again automatically if it crashes). All bugs will be looked at. When we switch over the website stuff, I'll take a look at rephrasing that section a little. >>> If I start PulseAudio in the user mode, only one user gets a sound card; >>> the second one gets "Dummy Output". >> >> Yeah, that's either because the second user does not have permission to >> access the device (due to ConsoleKit ACLs only the "active" >> (ck-list-sessions) user should get the ACL, but this could actually >> cover both users in your setup) or due to the fact that the card can >> only be opened once. >> >> Normally what you'd due is define some kind of udev magic that defines >> "seats" and thus contextually assigns certain USB ports and/or h/w to a >> given seat. Then when a user (any user - it's not tied to the seat) logs >> in, console-kit and udev both apply the right ACLs and PA can start and >> only show the relevant sound cards to the relevant seats. This is how it >> should work in an ideal world - everyone getting their own stuff. But in >> a situation where you accept all the problems listed above (things like >> security likely don't apply when people know each other :)) then system >> wide is fine. >> >> Hope that helps :) > > Well, the theory is nice :) but from user's perspective, sound with > multiseat became unreliable when distributions migrated to PulseAudio > (not that the life of a multiseat user was ever easy, but still, it's > yet one thing which discourages multiseat). > > Perhaps I'll try to see why PA crashes/exits when used by multiple users > in the system mode, report it to the mailing list, and hope won't get > too many "system mode is unsupported, go away" replies ;) Yeah, please do that :) If you can somehow manage to get a backtrace out of it that would be great. I find running gdb separate and connecting to PA with the appropriate "handle..." line before continueing is the best way to get a good backtrace. I guess leaving it running in a screen and waiting for a crash is the best approach here? Some info (including the handle line mentioned above): http://pulseaudio.org/wiki/Community#BugsPatchesTranslations 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] multiseat and PulseAudio?
'Twas brillig, and Tomasz Chmielewski at 16/05/11 09:49 did gyre and gimble: > On 16.05.2011 08:49, David Henningsson wrote: >> On 2011-05-14 17:46, Tomasz Chmielewski wrote: >>> Traditionally, UNIX systems were supporting multiseat desktop sessions >>> (i.e. multiple keyboards, video cards, monitors attached to one PC). >>> >>> According to: >>> >>> http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode >>> >>> What is wrong with system mode? >>> >>> Or with other words: if you run it that way on your desktop, >>> then you are doing it the wrong way. >>> >>> >>> What is the correct way to use PulseAudio with multiseat systems? >> >> Assuming there is also one sound card per seat, you should run one >> PulseAudio per seat, and as the user currently logged in to that seat. >> Exactly how to do that, i e set up access to the right sound card for >> the logged in user (with ConsoleKit etc) is beyond my knowledge though. > > I only have one sound card in the PC. > > It works fine when I start PulseAudio in the system mode, but according > to documentation, this is unsupported, strongly discouraged and should > only be used in some embedded setups. > So I'd like to do it "the right way" - unfortunately, PulseAudio > documentation does not explain how to setup PulseAudio with multiseat. Well in this evironment, I'd say that if you only have one card to be shared between the seats, then system wide mode is likely the right option. It's not nice generally because: 1. We cannot use SHM for memory transfer leading to more memcpy overhead. 2. One user can spy on the other user monitor their VOIP streams etc. 3. Module loading is disabled (for security) by default on system wide which IIRC affects hotplug etc. 4. There are some issues with Bluetooth permissions for BT devices (it can be configured of course but finding it is tricky - I've got mails flagged in my inbox to add this documentation at some point). And we don't test it particularly heavily, but all in all it should work fine (assuming you write your own init script and/or your distro does that for you). > If I start PulseAudio in the user mode, only one user gets a sound card; > the second one gets "Dummy Output". Yeah, that's either because the second user does not have permission to access the device (due to ConsoleKit ACLs only the "active" (ck-list-sessions) user should get the ACL, but this could actually cover both users in your setup) or due to the fact that the card can only be opened once. Normally what you'd due is define some kind of udev magic that defines "seats" and thus contextually assigns certain USB ports and/or h/w to a given seat. Then when a user (any user - it's not tied to the seat) logs in, console-kit and udev both apply the right ACLs and PA can start and only show the relevant sound cards to the relevant seats. This is how it should work in an ideal world - everyone getting their own stuff. But in a situation where you accept all the problems listed above (things like security likely don't apply when people know each other :)) then system wide is fine. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.
'Twas brillig, and David Henningsson at 16/05/11 07:23 did gyre and gimble:
> On 2011-05-15 16:45, Tanu Kaskinen wrote:
>> On Sun, 2011-05-15 at 17:43 +0300, Tanu Kaskinen wrote:
>>> This was discussed on the mailing list:
>>>
>>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html
>>>
>>> ---
>>> src/modules/alsa/alsa-mixer.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/src/modules/alsa/alsa-mixer.c
>>> b/src/modules/alsa/alsa-mixer.c
>>> index f236da0..8375a2f 100644
>>> --- a/src/modules/alsa/alsa-mixer.c
>>> +++ b/src/modules/alsa/alsa-mixer.c
>>> @@ -893,7 +893,7 @@ static int element_set_volume(pa_alsa_element *e,
>>> snd_mixer_t *m, const pa_chann
>>>
>>> if (e->has_dB) {
>>> long value = to_alsa_dB(f);
>>> -int rounding = value> 0 ? -1 : +1;
>>> +int rounding = e->direction == PA_ALSA_DIRECTION_OUTPUT
>>> ? +1 : -1;
>>>
>>> if (e->volume_limit>= 0&& value> (e->max_dB * 100))
>>> value = e->max_dB * 100;
>>
>> David, are you happy with this change, or does this require more
>> discussion?
>>
>
> I think it's OK. I think your theory is at least as good as mine, so
> let's give it a try. For HDA Intel this does not make much of a
> difference as Playback almost always only goes up to 0 dB whereas
> Recording usually is above 0 dB (although not always).
Cool. I'll have to try this out in my tree with Source Output volumes as
I'm having a brain freeze as to whether or not this is the right way
round for what I observed. If it's not working I'll post back with some
numbers.
> Might be worth adding a comment referring to the discussion behind the
> reasoning though.
Yeah, I think a comment would be wise when this goes in.
I'll take care of it and report back sometime this week.
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] loopback: Add a modarg for disabling remixing.
'Twas brillig, and Paul Menzel at 15/05/11 23:17 did gyre and gimble: > Am Sonntag, den 15.05.2011, 15:12 +0100 schrieb Colin Guthrie: >> Thought this one may be coming :) >> >> In my tree now. > > Does some documentation need to be added? Yeah the modules page on the wiki could always do with updating (there are several undocumented modules there too). It would be really nice to be able to create documentation automatically from the source tree... but that's a larger project! 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] bluetooth: Add missing return statement.
'Twas brillig, and Tanu Kaskinen at 14/05/11 13:37 did gyre and gimble:
> ---
> src/modules/bluetooth/module-bluetooth-device.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/modules/bluetooth/module-bluetooth-device.c
> b/src/modules/bluetooth/module-bluetooth-device.c
> index 086fce9..ae522bc 100644
> --- a/src/modules/bluetooth/module-bluetooth-device.c
> +++ b/src/modules/bluetooth/module-bluetooth-device.c
> @@ -1957,6 +1957,8 @@ static int sco_over_pcm_state_update(struct userdata
> *u, pa_bool_t changed) {
>
> return 0;
> }
> +
> +return 0;
> }
>
> static pa_hook_result_t sink_state_changed_cb(pa_core *c, pa_sink *s, struct
> userdata *u) {
Took a slightly different approach with this one to tidy up the early
return code a little (quite subjective but I prefer to not use else's
when the end of the first if has a return...)
Cheers
Col
commit ce8b03bb26243f01623699a115a34706b1348b77
Author: Colin Guthrie
Date: Sun May 15 15:05:44 2011 +0100
bluetooth: Fix early return styling and add missing return value
Thanks to Tanu Kaskinen for pointing out the missing return.
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 086fce9..1ff752a 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -1936,10 +1936,11 @@ static int sco_over_pcm_state_update(struct
userdata *u, pa_bool_t changed) {
if (u->transport)
return bt_transport_acquire(u, TRUE);
-else
-return start_stream_fd(u);
-} else if (changed) {
+return start_stream_fd(u);
+}
+
+if (changed) {
if (u->service_fd < 0 && u->stream_fd < 0)
return 0;
@@ -1954,9 +1955,9 @@ static int sco_over_pcm_state_update(struct
userdata *u, pa_bool_t changed) {
pa_close(u->service_fd);
u->service_fd = -1;
}
-
-return 0;
}
+
+return 0;
}
static pa_hook_result_t sink_state_changed_cb(pa_core *c, pa_sink *s,
struct userdata *u) {
--
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] loopback: Add a modarg for disabling remixing.
Thought this one may be coming :) In my tree now. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/4] suspend-on-idle: Trigger mempool vacuuming
'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble: > From: Jyri Sarha > > In a setup with one or more filter sinks or sources there is always at > least one stream existing. In such a situation normal mempool > vacuuming never happens. This patch causes suspend-on-idle module to > vacuum memory when ever it notices that all sinks and sources are > suspended. The behavior can be enabled with a module parameter. Thanks, in my tree 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] [PATCH 4/4] alsa-mixer: Add force-hw-volume flag to alsa profile sets
'Twas brillig, and Jyri Sarha at 11/04/11 10:19 did gyre and gimble: > On Sat, 09 Apr 2011 20:20:40 +0200, David Henningsson > wrote: >> On 2011-04-08 17:18, Colin Guthrie wrote: >>> 'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble: >>>> From: Jyri Sarha >>>> >>>> Before this patch, if any of the paths in a path set do not >>>> support HW volume then the HW volume is disabled for the whole >>>> set. In some cases this is a bit drastic measure. For instance, >>>> if all but one of the paths support HW volume and dB there no >>>> problem to pretend that we have HW volume for the whole set. The >>>> path without any mixers to control will just always return 0 dB >>>> and the rest is handled by SW volume. This patch adds a flag to >>>> the mapping section of profile set file to enables this behavior. >>> >>> David, this sounds similar to your USB Headset issue from a couple days >>> ago... or am I just reading too much into the description? >> >> Sort of - it just feels like neither of us has tried to do the right >> thing so far - I added a workaround/quirk for a few devices, and this >> patch adds a setting to turn something on and off. >> >> I'd like it to "just work". >> >> Or put in another way - what's the recommended default setting of this >> new parameter, and why? >> > > Target for my patch was to be non intrusive, but if you agree I can easily > > change my patch to always behave like force-hw-volume flag was set to true > and remove the flag. It is even easier just to change the default for the > flag. David, what's you're thinking on Jyri's suggestion here? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] protocol-native: Stop auto timing updates if connected to suspended sink or source
'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble: > From: Jyri Sarha > > This quite is an old patch. It was added to N900 to avoid unnecessary > wake-ups when the phone is in power save mode (= blank screen and > no user interaction). In this situation if the user had a browser > window with flash animation open pulseaudio kept waking up every > 10 seconds, causing a severe hit to use times. > > Anyway I do not see any reason to send timing updates if the sink or > source where the stream is connected to is suspended. Agreed. This should also be the case when the stream is corked too IMO... In my tree 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] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 15/05/11 05:41 did gyre and gimble: > On Tue, 2011-05-03 at 09:25 +0100, Colin Guthrie wrote: >> 'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: >>>>> In e193c2bf55326a48e2297bcacadc9d1848a40d7d and >>>>> 948d0f19bef353208ffb5b1b8c520b6b489b94a6 >>>>> >>>>> Can you make sure that pactl and pacmd stay as in-sync as possible? >>> I held off because I thought that pacmd was going to be dropped before >>> too long. Is this not the case? Sink port information seems to have not >>> been added, I'll sync that as well if required. >> >> Hmm, not sure. Ideally I'd prefer to just have one tool and only add to >> pacmd the things that cannot easily be done via the protocol, but I'm >> not sure of the overall strategy. >> >> I'll add this to the discussion points for Saturday's chat. > > Was this discussed? Any news? Sorry, I've not been awesome at writing up my notes. Am going to attempt to clear the decks today :D So pacmd is staying. It should be considered a debug tool however and pactl should be used for 99% of user interaction. For that reason, pacmd output can change more readily (i.e. the formatting can be adapted as/when needed), but pactl output is slightly more "fixed" due to people perhaps parsing it in scripts. >>>>> In bb7cc499f1815de1c90b0ef1850152224df96ff9 >>>>> >>>>> I don't see why this asserts in the current form nor what has actually >>>>> changed. >>> It should not assert since we want to gracefully fail (that is the >>> original code should not have been an assert). >> >> I still don't see any asserts in the original code. The only difference >> I can see is that a pa_log_debug() is not printed... (the log message >> says the word "Assertion" but it doesn't actually assert AFAICT...) >> >> This might be intended (i.e. don't print the log message), but if that's >> the case the commit message is still wrong to mention asserts... > > Ah, I see what you mean. Commit message amended. Cool. >>>>> General Question: >>>>> >>>>> Has this broken tunnels? (we manage to do this quite often with stream >>>>> protocol changes... >>> Indeed, it does. I've put fixing this on my TODO list. Will try to get >>> to it soon. >> >> Cool, thanks :) > > Done and pushed to my tree. :) Awesome. I'll merge it today most likely. Further fixes can be done on master with wider testing :) 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] Is there any way to remap source channels?
'Twas brillig, and Tanu Kaskinen at 13/05/11 16:55 did gyre and gimble: > On Fri, 2011-05-13 at 14:14 +0200, mar...@saepia.net wrote: >> Why should I prevent remixing? Can't I just use module-loopback with >> channel_map set? > > I think this is what happens (I haven't tested): if you have non-aux > channels on the sound card, let's say front-left, front-right, rear-left > and rear-right, and you try to loop back just rear-left and rear-right, > the resampler (which really takes care of more conversion than just > sample rate) will try to be smart and mix some of front-left and > front-right into the rear-left and rear-right channels. The same logic > is involved always when a stream - be it capture or playback - is > connected to a device that doesn't have the same parameters as the > stream. Configuring the device to use aux channels should disable the > "intelligent" remixing - only the channels specified by the stream will > be taken from the source. FWIW, some modules, like module-remap-sink take a remix=yes|no argument to control this behaviour even when using standard channel names. 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] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and David Henningsson at 13/05/11 16:29 did gyre and gimble: > On 2011-05-13 09:49, Tanu Kaskinen wrote: >> Hello, >> >> Should this commit be reverted? > > No. > >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920 >> >> >> I don't know what problem that commit solves,but it introduces a new >> problem: if Pulseaudio requests a volume that is above 0dB in the alsa >> volume element scale, then it can easily happen that alsa will round the >> request down. That rounding is then compensated with software volume, >> which in this case is amplification. We don't want software >> amplification, or do we? > > In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB) > and the user wants 30 dB, better have 20dB in hardware and +10dB in > software than 40dB in hardware and -10dB in software, as the latter one > is more likely to have digital distortion when the signal passes through > the ADC. I can see the point in this, but there is still something ultimately wrong in the logic when dealing with pa_cvolume_divide when calculating what volume to write to the h/w (this is in an uncommitted patch to add flat volumes to sources and thus volume controls to source outputs). By rounding in this direction I find the calculated h/w volume very sporadic whereby ramping up the volume smoothly in PA will actually cause the alsa volume to go up and down as it climbs e.g. at 72% alsa was at e.g. +16dB and at 73% it was at +14.5dB which makes no logical sense. Perhaps the logic behind using pa_cvolume_divide has not been ported properly (by me) in my patch, but I think we'll need to look at this approach a bit to try and work out what's happening and how to fix it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and Colin Guthrie at 13/05/11 09:06 did gyre and gimble: > Wow spooky. Strangely enough I've already got this one reverted in my tree! I didn't mean to use the word "reverted" there but you catch my drift I'm sure. 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] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and Tanu Kaskinen at 13/05/11 08:49 did gyre and gimble:
> Hello,
>
> Should this commit be reverted?
>
> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920
>
> I don't know what problem that commit solves, but it introduces a new
> problem: if Pulseaudio requests a volume that is above 0dB in the alsa
> volume element scale, then it can easily happen that alsa will round the
> request down. That rounding is then compensated with software volume,
> which in this case is amplification. We don't want software
> amplification, or do we?
Wow spooky. Strangely enough I've already got this one reverted in my tree!
I found that when adding source output volumes (which I will publish
after Arun's passthrough work is merged), that this caused really
strange issues with volume.
This is the commit in my tree that solved that:
commit 8b595ac248d7ca48e28c3e4e84f1eaf4abf5439d
Author: Colin Guthrie
Date: Sun May 8 12:44:50 2011 +0100
alsa-mixer: Reverse rounding direction for sources.
The previous logic in ade0a6f88464d8aecf83982d400ccfc402341920
does not work with for input volumes.
In the case of input 0dB is typically the point at which ALSA sliders
are their minimum. This means that when the ALSA mixer is at it's
maximum it could be applying e.g. +22.5dB.
Considering a step size of ±1.5dB, if we request +22dB, the current
system will ultimate set the h/w to +21dB (one step below +22.5dB)
because it rounds towards 0. This means that software has to amplify the
signal back up to +22dB which is obviously not ideal for the data
integrity. So for inputs we should always go higher than we request if
possible and then attenuate in software back down to the level
requested.
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index f236da0..1d9a91a 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -893,7 +893,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
if (e->has_dB) {
long value = to_alsa_dB(f);
-int rounding = value > 0 ? -1 : +1;
+int rounding;
if (e->volume_limit >= 0 && value > (e->max_dB * 100))
value = e->max_dB * 100;
@@ -903,6 +903,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
* if the channel is available, ALSA behaves very
* strangely and doesn't fail the call */
if (snd_mixer_selem_has_playback_channel(me, c)) {
+rounding = value > 0 ? -1 : +1;
if (e->db_fix) {
if (write_to_hw)
r = snd_mixer_selem_set_playback_volume(me,
c, decibel_fix_get_step(e->db_fix, &value, rounding));
@@ -925,6 +926,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
r = -1;
} else {
if (snd_mixer_selem_has_capture_channel(me, c)) {
+rounding = value > 0 ? +1 : -1;
if (e->db_fix) {
if (write_to_hw)
r = snd_mixer_selem_set_capture_volume(me,
c, decibel_fix_get_step(e->db_fix, &value, rounding));
--
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] Assertion '(size_t) decoded == a2dp->frame_length' failed at modules/bluetooth/module-bluetooth-device
Hiya 'Twas brillig, and h.pa...@accenture.com at 12/05/11 07:41 did gyre and gimble: >I am using pulse audio 0.9.21(Tried 0.9.22 also) on arm with > bluez-4.89(Tried 4.93 also) but getting the following error. > >I am running pulseaudio in system mode as i am having only > root user on my target. I've a funny feeling this is perhaps fixed in git master. Please try that :) This previous thread seems relevant: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/8859 And these two commits might be the winners for you: commit b676f89d8579c7ec1629892342a330f1e4c35657 Author: Colin Guthrie Date: Sun Mar 20 11:44:53 2011 + bluetooth: Run 'make update-sbc' Note that changes to ipc.h from 8f3ef04b had to be manually reapplied. commit 0bed5caf3b9fedfce2100cc85de344670ddbb386 Author: Paul Menzel Date: Tue Mar 29 12:14:27 2011 +0200 bluetooth: run `make update-sbc` to pull in build fix for thumb mode This update pulls in commit c495077c [1] to fix a build error. commit c495077cf8a8c37afd90875ec5a5b16b294be15e Author: Siarhei Siamashka Date: Tue Mar 29 01:57:39 2011 +0300 sbc: better compatibility with ARM thumb/thumb2 ARM assembly optimizations fail to compile in thumb mode, but are fine for thumb2. Update ifdefs in the code to make use of ARM assembly only when it is safe and also make sure that no optimizations are missed when compiling for thumb2. The problem was reported by Paul Menzel: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-February/009022.html This patch is tested with OpenEmbedded using `minimal-uclibc` for `MACHINE = "at91sam9260ek"`. Note that changes to ipc.h from 8f3ef04b had to be manually reapplied. [1] http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=c495077cf8a8c37afd90875ec5a5b16b294be15e PS, the disclaimer doesn't make any sense :D -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Are "_ref" and "_unref" not necessarily called in pairs?
Hiya,
As per the subject question... Yes, they are supposed to be called in
pairs... BUT
'Twas brillig, and Lin, Mengdong at 12/05/11 09:31 did gyre and gimble:
> For example, in file “module-suspend-on-idle.c “, why does the slot
> function “sink_input_state_changed_hook_cb” only reference the sink
> input but never unreference it?
>
> So the reference count of the sink input will only increase? Does it matter?
>
> Here is the code:
>
> static pa_hook_result_t sink_input_state_changed_hook_cb(pa_core *c,
> pa_sink_input *s, struct userdata *u) {
>
> struct device_info *d;
>
> pa_sink_input_state_t state;
>
>
>
> pa_assert(c);
>
> pa_sink_input_assert_ref(s); … the sink input is referenced here.
> But where pa_sink_input_unref(s) is called?
This is not the same as pa_sink_input_ref(). Note the word "assert" in
the "function" call in the code above (it's actually a define, not a
function but I won't split hairs with myself :D).
Here all that is happening is ensuring that the sink_input object is
referenced...
The code is in pulsecore/object.h
See lines 91, and 69.
The code basically means assert if the object is not referenced. This is
a safefy thing to ensure good programming of modules etc.
Hope that clarifies things.
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] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 11/05/11 19:56 did gyre and gimble: > > On May 11, 2011, at 6:43 AM, Colin Guthrie wrote: > >> 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did >> gyre and gimble: >>> This is the third version of the Pulseaudio and UCM integration. >>> >>> >>> This set of patches cover adding ucm data to proplist, adding a >>> ucm API to get and set data to proplist, and lets >>> module-alsa-card scan ucm data when the card is probed. >>> >>> Another set of patches dealing with jack module detection will >>> be sent separately. >> >> Thanks for this. I believe David will be helping review this >> stuff, but is currently at UDS. >> >> WRT the jack detection, I think we all agreed that it needs to be >> handled more internally in the alsa code rather than separated as >> a module. >> >> I'm not 100% sure of the finer details but I know David had ideas >> here too. >> >> We basically need to match up the jack stuff with the appropriate >> sink/source device on the system and then develop a way to >> automatically change sink/source ports accordingly (it may also >> require that we change the card profile too - e.g. change from a >> 5.1 profile to a stereo profile when plugging in stereo >> headphones). > > Unfortunately, the jack matching to source is not that clever yet in > the drivers. :( There is no way to really be sure that Jack X > matches stream Y. This information should be available in the future > though (for ASoC drivers at least) when the DAPM graphs are exported. > In the mean time all we can do is know whether a jack is inserted or > removed for a particular sound card. I thought it reported some fairly useful names I'm sure David had some way to see some degree of info. For example on my machine: [root@jimmy ~]# cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xefebc000 irq 43 [root@jimmy ~]# evtest /dev/input/event7 Input driver version is 1.0.1 Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0 Input device name: "HDA Intel Mic at Ext Right Jack" Supported events: Event type 0 (Sync) Event type 5 (?) Event code 4 (?) Testing ... (interrupt to exit) So the string "HDA Intel" is present in both which we should be able to match up. >> I'm not sure how to detect multiple jacks - e.g. if you plug in 3 >> jacks to do 5.1 output, should 5.1 be handled automatically? > > Again, this is something that requires better driver and core alsa > support. Well not sure. I'd expect the different jacks to have different /dev/input/event* inputs with different jack names on them, so we should (in theory) be able to match that up no? >> Anyway, all the jack detection stuff should be totally separate >> from UCM stuff and could in theory be committed first. UCM should >> just hook into port/profile changes for pushing new configs up to >> ucm and set the appropriate verb+modifiers on the device. > > Ok, I'll copy the jack code we have into module-alsa-card. This will > allow for simple jack removal/insertion events to be propagated to > pulseaudio. We won't be able to do the complicated stuff mentioned > above, but should at least be able to do simple speaker/headphone > switching. Cool. Like I say it's probably worth chatting with David about it before coding too much, but I'm not sure how contactable he is due to UDS focus right now. It's not possible to do anything with jack detect unless we can match up the events with the device. If we can't do that, then we're stuck (e.g. imagine if the user has two sound cards) so I hope what I wrote above is indeed true! 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] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre and gimble: > This is the third version of the Pulseaudio and UCM integration. > > This set of patches cover adding ucm data to proplist, adding a ucm API > to get and set data to proplist, and lets module-alsa-card scan ucm data > when the card is probed. > > Another set of patches dealing with jack module detection will be sent > separately. Thanks for this. I believe David will be helping review this stuff, but is currently at UDS. WRT the jack detection, I think we all agreed that it needs to be handled more internally in the alsa code rather than separated as a module. I'm not 100% sure of the finer details but I know David had ideas here too. We basically need to match up the jack stuff with the appropriate sink/source device on the system and then develop a way to automatically change sink/source ports accordingly (it may also require that we change the card profile too - e.g. change from a 5.1 profile to a stereo profile when plugging in stereo headphones). I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks to do 5.1 output, should 5.1 be handled automatically? Anyway, all the jack detection stuff should be totally separate from UCM stuff and could in theory be committed first. UCM should just hook into port/profile changes for pushing new configs up to ucm and set the appropriate verb+modifiers on the device. (disclaimer, my UCM foo is still not awesome, but I think this is all the consensus we reached on the matter!). 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] echo-cancel: Remove unnecessary noalign attribute
'Twas brillig, and Arun Raghavan at 10/05/11 09:03 did gyre and gimble: > This was just introduced for debugging and should not have been in the > final commit. Won't make a difference at the moment since this function > is used as a pointer, but removing this in case we change this in the > future. Thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] echo-cancel: Handle alignment requirement manually
'Twas brillig, and Arun Raghavan at 09/05/11 09:10 did gyre and gimble: > PA_ALIGNED can't always guarantee that the alignment we want (the GCC > man page suggests that the linker might not be able to meet the > alignment requirements we desire). Instead, we now allocate some extra > memory and guaratee that the alignment we require is met. Looks fine (but sad that it's not easier). 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] How pulseaudio support autospawn?
Hello, 'Twas brillig, and Lin, Mengdong at 10/05/11 08:37 did gyre and gimble: > How pulseaudio support autospawn? > > After pulse audio daemon is killed manually, how it will be executed > automatically? How can it know some client is attempts to connect to > it? Could someone introduce its internal implementation? This is performed automatically by libpulse. All pulseaudio client appliations (be them native applications supporting PA directly or an ALSA application using the alsa->pulse plugin) use libpulse. It has code that tries to connect to the daemon, and if that connection fails it will automatically attempt to spawn a pulseaudio daemon and then connect to it. There are some exceptions to this e.g. * when the client application is trying to connect to a remote address. * when autospawn=no is set in client.conf * possibly a couple more I forget off the top of my head :D > > I got a explanation of autospawn: “ if the daemon is not running when > the first client attempts to connect, it will be executed automatically” > > (From > http://www.linux-archive.org/ubuntu-development/246411-notable-changes-jauntys-pulseaudio.html) > But I hope someone can give more detail. So the code itself is here: http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/pulse/context.c;h=1480af533a57cc4eca39bff405973ba4bc8f94c6;hb=HEAD#l802 which is triggered from here: http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/pulse/context.c;h=1480af533a57cc4eca39bff405973ba4bc8f94c6;hb=HEAD#l868 Hopefully you can follow things through from here, but feel free to ask any other questions if you're stuck :) 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] PulseAudio automatically shutting down?
'Twas brillig, and mar...@saepia.net at 10/05/11 12:35 did gyre and gimble: > Hi, > > I am running pulseaudio 0.9.21-63-gd3efa-dirty from ubuntu 10.10 packages. > > I need to use pulseaudio in the server environment to perform audio > routing tasks. > > I run it with minimal configuration: > > load-module module-null-sink sink_name=tuned_fake > load-module module-rescue-streams > load-module module-always-sink > load-module module-intended-roles > set-default-source tuned_fake.monitor > set-default-sink tuned_fake > > It seems that if no client is connected, daemon exits after some > (short, +/- 1 min) time. > > Is it correct behaviour? > > Thank you in advance, Yup! man pulse-daemon.conf and see "exit-idle-time" :D HTHs 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] unambiguous tag names in the repository
Hiya, 'Twas brillig, and Paul Menzel at 07/05/11 09:22 did gyre and gimble: > I just read the blog post > > Please use unambiguous tag names in your DVCS [1] > > which for security reasons suggests to use unambiguous tag names. > > Therefore I suggest to change our tag name scheme to the following. > > pa_0.9.22 or pa_1.0 Personally I disagree. I think short tag names makes life easier when working on multiple projects and in our case our actual package version is generated directly from the git tag using git's built in versioning capabilities (where is searches for a tag then produces a version number based on that tag and the number of commits since then) Now we could adapt our git-version-gen script easily enough, but I really don't see the point. If others feel really strongly about this then fine, but I think the reasons given in the blog are somewhat hypothetical and not really very likely in the real world (and in the unlikely even of it happening at some point in the future, then we can take the time to rename tags then) Just my €0.02 :) 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] several seconds delay while playing video with timer-based audio scheduling enabled
'Twas brillig, and xing wang at 05/05/11 10:24 did gyre and gimble: > Hi community, > > I met a weird issue when playing video on Meego Platform. > if turn on timer-based audio scheduling, there's nearly seconds voice > delay during playing video. > The abnormal phenomenon disappeared after turn it off. > > I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions > (http://0pointer.de/blog/projects/pulse-glitch-free.html) > the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio, > newest everything. > > After some google search, there's no obvious finding about similar > issues. Meanwhile i guess the official release of glitch-free > must be verified about "tsched" feature, so it's not a bug but a usage > mistake,such as some config file wrong for my platform. > > So if anyone had meet same issue or could you provide some > suggestions, that would be appreciated much. What video player is being used? It is perhaps making some really dumb assumptions about things and thus breaking (and using too much power too!) 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] rewind and underrun issues on start of playback
Hi, 'Twas brillig, and Dan Muresan at 03/05/11 19:51 did gyre and gimble: >> I think you are correct in that there is an alsa bug. It seems that >> pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio >> 0.9.22 does. > > I asked before, but for some reason never got an answer from this > list: is there a simple way to disable rewinds? They seem to be > related to excessive real-time CPU usage, causing rlimit_rttime to be > exceeded (and pulse to be KILL'ed by the kernel). >From earlier in this thread: 'Twas brillig, and Tanu Kaskinen at 01/05/11 08:22 did gyre and gimble: > On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote: >> > Is there a way to prevent these rewinds/underruns when starting playback? > > Not to my knowledge, except by changing the code. I'm pretty sure that's correct (tho' I won't pretend to know the alsa code in very much depth). 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] rewind and underrun issues on start of playback
'Twas brillig, and Baek Chang at 02/05/11 04:52 did gyre and gimble: > Also, if i revert to pulseaudio 0.9.14, i do not see this issue > happening. I can hear the very short samples in the beginning fine. I think generally that the rewinding should work, and that by reverting you are just bypassing a bug at (perhaps) the alsa level which should really be fixed. I suspect if you can create a (very simple) alsa test application that exhibits the problem (by using rewinds) then this can be taken to the alsa-devel list in order to fix the underlying problem. That's my take on it anyway, and I could of course be wrong! 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] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: >> > In e193c2bf55326a48e2297bcacadc9d1848a40d7d and >> > 948d0f19bef353208ffb5b1b8c520b6b489b94a6 >> > >> > Can you make sure that pactl and pacmd stay as in-sync as possible? > I held off because I thought that pacmd was going to be dropped before > too long. Is this not the case? Sink port information seems to have not > been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. >> > In bb7cc499f1815de1c90b0ef1850152224df96ff9 >> > >> > I don't see why this asserts in the current form nor what has actually >> > changed. > It should not assert since we want to gracefully fail (that is the > original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word "Assertion" but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... >> > General Question: >> > >> > Has this broken tunnels? (we manage to do this quite often with stream >> > protocol changes... > Indeed, it does. I've put fixing this on my TODO list. Will try to get > to it soon. Cool, thanks :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] filter-apply: Mark modules as being autoloaded
'Twas brillig, and Arun Raghavan at 02/05/11 05:41 did gyre and gimble: > (Based on Colin's review) We mark modules as being autoloaded so that > they can handle this as a special case if needed (which is required by > module-echo-cancel for now). This inverts how things were done and makes > using these modules manually less error-prone. Thanks :) Yeah, although this pushed a convention to filter module, I think this is a better approach than getting people loading things manually to do something special :) In ma tree! 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] Make connect-stress test compile for win32
Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] ANN: Rename of module-combine
Hi, I've renamed module-combine to module-combine-sink as that's what it is. I've kept a wrapper called module-combine so exiting setups will still work fine (in theory) even using the old name. I've tested and paprefs still works OK without modification. I will probably patch paprefs at some point, but by the same token I want it to die at some point anyway, so maybe won't bother. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/3] bluetooth: fix not updating sample spec when using Media API
'Twas brillig, and Luiz Augusto von Dentz at 29/04/11 15:48 did gyre and gimble: > From: Luiz Augusto von Dentz > > When using transport configured via Media API sample spec needs to be > updated since codec configuration may affect it when e.g. headset > configure a different frequency or number of channels from default. Thanks. All three patches now 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] Cleanup of configure.ac
'Twas brillig, and Maarten Bosmans at 30/04/11 14:25 did gyre and gimble: > This patch series cleans up the --enable- handling part of > configure.ac. > It changes the testing of features so that they are all done in the same way. > > The linecount of configure.ac is reduced from around 1800 with 450 lines. > This is partly because os using macro's, > partly due to simplification of if/else logic and also a bit due to rewriting > stuff to one line. I think the > readability of configure.ac is greatly improved. Nice :) > The only feature that is lost is the error message when --enable-foo=arg is > used with arg something other than yes or > no. Instead now silently the default is used. This is no big loss IMHO, > because usually just --enable-foo or > --disable-foo is given to configure. I didn't even now you could call it with --enable-foo=no so I totally agree that it's much more common to use --enable-foo or --disable-foo. Not a great loss IMO. > [PATCH 1/7] build-system: Simplify AC_ARG_ENABLE usage I had to modify slightly due to XCB patch in my tree... nothing major tho' (just the pkg-config stuff relating to xcb deps). > [PATCH 2/7] build-system: Use AS_IF macro for configure output > [PATCH 3/7] build-system: Move AC_DEFINE to separate line with AS_IF > [PATCH 4/7] build-system: Move dependency error messages to outer scope > [PATCH 5/7] build-system: Replace some more conditionals with AS_IF As per patch 1 above. > [PATCH 6/7] build-system: Rearrange database selection > [PATCH 7/7] build-system: Small fixes Pushed now :) Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/2] Fixing module-dbus-protocol unloading
'Twas brillig, and Tanu Kaskinen at 29/04/11 11:58 did gyre and gimble: > There were a couple of crash bugs in the > module-dbus-protocol unloading code, which became visible > when unloading the module while there were still clients > connected. > > Tanu Kaskinen (2): > dbus: Fix connection idxset freeing when unloading the module. > dbus: Fix the order of freeing stuff when unloading > module-dbus-protocol. > > src/modules/dbus/module-dbus-protocol.c | 29 +++-- > 1 files changed, 15 insertions(+), 14 deletions(-) Thanks, in my tree 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] [PATCH] match: Support for both merging and replacing proplist updates.
'Twas brillig, and Tanu Kaskinen at 29/04/11 11:45 did gyre and gimble: > This patch adds a new update mode specifier that can be optionally > given in match rules after the regexp. Propertly list updates triggered > by the rule will honour the given mode. The two allowed modes are 'merge' > and 'replace', corresponding to PA_UPDATE_MERGE and PA_UPDATE_REPLACE > respectively. If omitted, the mode defaults to PA_UPDATE_MERGE, ie. to > the original behavior. > > For example, to force 'media.role' to be overwritten with 'bar' for > streams matching foo you can use an entry like this: > > foo replace "bar" > > This will really overwrite media.role to bar even if it has already been > set to something else by the application. > > Thanks to Krisztian Litkey for the original patch and the description > above. In addition to implementing the new feature, this patch fixes > a number of bugs in the parsing code. Looks sensible to me with a quick parse... in my tree 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] [PATCH] module: new null-source module
'Twas brillig, and Tanu Kaskinen at 27/04/11 12:59 did gyre and gimble: > On Wed, 2011-04-27 at 14:50 +0300, Tanu Kaskinen wrote: >> From: Marc-André Lureau >> >> --- >> src/Makefile.am |6 + >> src/modules/module-null-source.c | 294 >> ++ >> 2 files changed, 300 insertions(+), 0 deletions(-) >> create mode 100644 src/modules/module-null-source.c > > This module isn't actually used by anyone currently. We (at Nokia) > switched to null-sink's monitor a long time ago (for reasons unknown to > me), so the code hasn't had much testing lately. Even though there are > no users for the module currently, I'm sending the patch anyway, just in > case people think that the module might be useful in some situation. > > I quickly tested that I can record silence with parec from source.null - > I can't give any further guarantees that the code is correct. I have tested this but not 100% sure it's totally correct... I've committed it anyway (we an always disable it easy enough if it doesn't pass QA :p I was able to load this and record from it but the vumeter in pavucontrol was quite active and jumpy and when doing parec|pacat I did get quite a lot of static (not a crazy amount, but more than I would expect from pure silence... I doubt resampling would have caused the level of static I saw). So there might be some weirdness in there with the "silence" it produces if anyone has a desire to have a peak Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] core: Drop empty gaps in the memblockq when playing data from it.
'Twas brillig, and Colin Guthrie at 20/04/11 15:04 did gyre and gimble: > 'Twas brillig, and Antti-Ville Jansson at 20/04/11 14:00 did gyre and > gimble: >> The assert that this patch fixes can be reproduced with e.g. the >> following script: >> >> >> SAMPLE_PATH="/usr/share/sounds/alsa/" >> SAMPLE="Front_Left" >> >> pactl remove-sample $SAMPLE 2> /dev/null >> pactl upload-sample $SAMPLE_PATH$SAMPLE.wav >> >> mod1=`pactl load-module module-null-sink sink_name=null1` >> mod2=`pactl load-module module-null-sink sink_name=null2` >> >> pactl play-sample $SAMPLE null1 >> >> input=`pactl list | grep "Sink Input #" | tail -n 1 | cut -d# -f2` >> >> echo "Sample $SAMPLE playing as Sink Input #$input" >> >> pactl move-sink-input $input null2 >> pactl move-sink-input $input null1 >> >> pactl unload-module $mod1 >> pactl unload-module $mod2 > > Thanks for the awesome test case. I'll take a look at this shortly :) I've had a play with this and can reproduce the problem with current git master and confirmed that your patch solved the issue. I've modified the commit message to include the above test case for completeness. Many thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] stream-restore: Enable database dumping if DEBUG_VOLUME is defined.
'Twas brillig, and Tanu Kaskinen at 28/04/11 10:57 did gyre and gimble: >> > Forgive my ignorance here but I cannot see where this is called... Is >> > there some magic way to call this function? > You can call it in gdb. Ahh of course. Silly me :) OK, consider it merged. 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-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases
'Twas brillig, and David Henningsson at 21/04/11 14:22 did gyre and gimble: > Due to a round-off error, snd_pcm_avail could in some cases > return 0 even though more data could be written to the stream. > > This was discovered by Maarten Lankhorst [1], and there is also a test > program available that triggers this error [2]. > > [1] > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009935.html > > > [2] > https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110420/3c852d6e/attachment.c For completeness (on this list), this patch has now been committed to alsa-lib. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] stream-restore: Enable database dumping if DEBUG_VOLUME is defined.
'Twas brillig, and Tanu Kaskinen at 27/04/11 11:08 did gyre and gimble:
> From: Tanu Kaskinen
>
> ---
> src/modules/module-stream-restore.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/modules/module-stream-restore.c
> b/src/modules/module-stream-restore.c
> index c1baf8f..56672f7 100644
> --- a/src/modules/module-stream-restore.c
> +++ b/src/modules/module-stream-restore.c
> @@ -1778,8 +1778,8 @@ static void apply_entry(struct userdata *u, const char
> *name, struct entry *e) {
> }
> }
>
> -#if 0
> -static void dump_database(struct userdata *u) {
> +#ifdef DEBUG_VOLUME
> +PA_GCC_UNUSED static void stream_restore_dump_database(struct userdata *u) {
> pa_datum key;
> pa_bool_t done;
>
Forgive my ignorance here but I cannot see where this is called... Is
there some magic way to call this function?
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] module: new null-source module
'Twas brillig, and Tanu Kaskinen at 27/04/11 12:59 did gyre and gimble: > On Wed, 2011-04-27 at 14:50 +0300, Tanu Kaskinen wrote: >> From: Marc-André Lureau >> >> --- >> src/Makefile.am |6 + >> src/modules/module-null-source.c | 294 >> ++ >> 2 files changed, 300 insertions(+), 0 deletions(-) >> create mode 100644 src/modules/module-null-source.c > > This module isn't actually used by anyone currently. We (at Nokia) > switched to null-sink's monitor a long time ago (for reasons unknown to > me), so the code hasn't had much testing lately. Even though there are > no users for the module currently, I'm sending the patch anyway, just in > case people think that the module might be useful in some situation. > > I quickly tested that I can record silence with parec from source.null - > I can't give any further guarantees that the code is correct. Yeah due to the fact that a null sink has a null monitor, this module is of limited usefulness, but I think it could still be useful in some cases where you do want a null recording but don't want it polluted with sinks. I did actually have someone that wanted to hook up null sources and null sinks to some Windows VMs a while back (several VMs but only one null sink+monitor source). He was annoyed that he could record other VMs output from within a separate VM on the monitor. Obviously he can shuffle around the various streams and create multiple null sinks but it would have actually been simpler to setup a null source in the first place. So I'll do some testing then grab it at some point (tho' need to spend some time reviewing Margarita's work before next week otherwise Liam and Mark will find some way to punish 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] how to set buffer attributes in 0.9.15
'Twas brillig, and Tanu Kaskinen at 25/04/11 18:15 did gyre and gimble: > If 0.9.14 worked as you want, the switch to timer-based scheduling > probably caused the change in behavior. If this application is used only > on systems where you can dictate the pulseaudio daemon settings, then > adding "tsched=0" to the line in /etc/pulse/default.pa where > module-hal-detect is loaded may help. I should also say that if it is timer-based scheduling that turns out to be the cause, then there have been lots of timing fixes committed in PA since 0.9.15 that may ultimately make your issue go away. (tho' if you really need fixed samples, then perhaps not...) 0.9.15 really is very old now, so unless you are completely restricted, I'd upgrade to the latest stable-queue (or at least 0.9.22). 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] review+pull-request: Passthrough support
'Twas brillig, and Arun Raghavan at 13/04/11 13:53 did gyre and gimble: > Hey folks, > My passthrough work is now at a point where I think it's good to pull to > master. All the core code for clients to signal that they are providing > a compressed format, and sinks to signal what formats they support is > there. The API is essentially the same as discussed earlier on-list, > with some small tweaks along the way as necessary. > > Still pending are proper detection/signalling of available formats on > ALSA devices is to be done (Colin's looking at some of the plumbing for > S/PDIF, and HDMI ELD/EDID-based lookups are something that we need as > well), and better handling of monitors (we suspend them for now, which > works), and volumes (Tanu's got some on-going work on this). > > NOTE: given the above about ALSA, topmost patch should probably not be > pulled, but is handy to have for testing. > > In addition to the passthrough branch, there is a passthrough-bt branch > which has changes to the bluetooth sink to support streaming MP3 to > headsets that support it. This also needs some work before being ready > to pull. > > The changes needed to actually use this in GStreamer are also done, but > not upstream yet. I need to do some rebasing to make this stuff good to > push out, so details on this in a following mail. > > Comments, feedback will be very much appreciated. :) > are available in the git repository at: > git://git.collabora.co.uk/git/user/arun/pulseaudio.git passthrough Not tried the code (yet), but will do this week. I have reviewed all the code yet! But I did review all the commits! Most of my comments are trivial tho' (and some are already fixed it seems!) In 4a839b3767ae5571c69bd591b5a59d7307cba13e pa_format_info_to_sample_spec() and pa_format_info_to_sample_spec_fake() some pa_assert's should pa_assert_se's. (Update: I think these are all rectified in 38309769c5a630ee78ae73be6fb407624c1509fc) In 7e8b65bc4f490628f20ab420a6c80bfa3a760bc6 Shouldn't pa_create_stream_callback() call pa_tagstruct_get_format_info() up to n_format times and only bail if all are invalid? Minor typo: "Send back the format me negotiated" s/me/we/ Minor typo: "We're working not working with the extended API" s/working not/not/ pa_sink_input_new_data_set_formats(): Please drop the last "else" and just put the "return TRUE" as the last statement. It's trivial but I believe this looks neater to always have a return at the top level of the function. In d885a39b9f1085e759ad69afcc939caffb1fbc5a Minor typo: "but this is can very well be incorrect" s/this is/this/ In e193c2bf55326a48e2297bcacadc9d1848a40d7d and 948d0f19bef353208ffb5b1b8c520b6b489b94a6 Can you make sure that pactl and pacmd stay as in-sync as possible? In bb7cc499f1815de1c90b0ef1850152224df96ff9 I don't see why this asserts in the current form nor what has actually changed. In 9d5e8867066e392fa40add0f0380374131dfc2de Minor: pa_streq has a space before the (. In d9e0f3bc0286249ced30a4728e4467f7a46f37af Already merged in 837e0a960630251ce30c124da5e65079b748d978 Should we rebase before merge or is it wise to keep your tree as is for ease of working with existing checkouts? General Question: Has this broken tunnels? (we manage to do this quite often with stream protocol changes... That is all! 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] More patches for better OS X support
'Twas brillig, and Colin Guthrie at 23/04/11 17:51 did gyre and gimble:
> 'Twas brillig, and Daniel Mack at 22/04/11 13:27 did gyre and gimble:
>> Here goes another round of patches for PulseAudio on OS X. Most patches
>> are small, and none of them should affect other systems than OSX.
>
> Thanks as always Daniel. I grabbed all the patches but tweaked the
> commit messages a little bit, so you'll need a rebase for the next
> batch. Hope that's OK :)
Oh, forgot to mention that I had to tweak the code a bit too (squashed
into your changes)... two problems I found:
1. A simple typo:
diff --git a/src/pulse/util.c b/src/pulse/util.c
index e44a864..48ccf29 100644
--- a/src/pulse/util.c
+++ b/src/pulse/util.c
@@ -226,7 +226,7 @@ char *pa_get_binary_name(char *s, size_t l) {
}
#endif
-#if OS_IS_DARWIN
+#ifdef OS_IS_DARWIN
{
int mib[] = { CTL_KERN, KERN_PROCARGS, getpid(), 0 };
size_t len, nmib = (sizeof(mib) / sizeof(mib[0])) - 1;
2. I found that HAVE_PTHREAD_SETNAME_NP was indeed defined on my system,
but that it takes two arguments here, not one. This caused build errors
for me.
Thus I made the following change:
diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
index ae73267..58bcb72 100644
--- a/src/pulsecore/thread-posix.c
+++ b/src/pulsecore/thread-posix.c
@@ -71,10 +71,10 @@ static void* internal_thread_func(void *userdata) {
pa_thread *t = userdata;
pa_assert(t);
-#ifdef HAVE_PTHREAD_SETNAME_NP
-pthread_setname_np(t->name);
-#elif defined(__linux__)
+#ifdef __linux__
prctl(PR_SET_NAME, t->name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
+pthread_setname_np(t->name);
#endif
t->id = pthread_self();
@@ -177,22 +177,17 @@ void pa_thread_set_name(pa_thread *t, const char
*name) {
pa_xfree(t->name);
t->name = pa_xstrdup(name);
-#ifdef HAVE_PTHREAD_SETNAME_NP
-pthread_setname_np(name);
-#elif defined(__linux__)
+#ifdef __linux__
prctl(PR_SET_NAME, name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
+pthread_setname_np(name);
#endif
}
const char *pa_thread_get_name(pa_thread *t) {
pa_assert(t);
-#ifdef HAVE_PTHREAD_GETNAME_NP
-if (!t->name) {
-t->name = pa_xmalloc0(17);
-pthread_getname_np(t->id, t->name, 16);
-}
-#elif defined(__linux__)
+#ifdef __linux__
if (!t->name) {
t->name = pa_xmalloc(17);
@@ -203,6 +198,11 @@ const char *pa_thread_get_name(pa_thread *t) {
t->name = NULL;
}
}
+#elif defined(HAVE_PTHREAD_GETNAME_NP) && defined(OS_IS_DARWIN)
+if (!t->name) {
+t->name = pa_xmalloc0(17);
+pthread_getname_np(t->id, t->name, 16);
+}
#endif
return t->name;
This should still work for you on OSX (if not, then I apologise!). I
added the OS_IS_DARWIN bit as the API for pthread_setname_np does not
appear to be totally stable (two args here, and I presume just one arg
on OSX).
I figured this may actually break windows stuff if it also has the
two-arg version, hence the additional check. Hope that makes sense.
Of course it may be possible to use pthread_setname_np on linux too
(albeit with it's two arg variant...) which could simplify the code a bit...
Both changes squashed into your commits.
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] More patches for better OS X support
'Twas brillig, and Daniel Mack at 22/04/11 13:27 did gyre and gimble: > Here goes another round of patches for PulseAudio on OS X. Most patches > are small, and none of them should affect other systems than OSX. Thanks as always Daniel. I grabbed all the patches but tweaked the commit messages a little bit, so you'll need a rebase for the next batch. Hope that's OK :) 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: An official system for enabling/disabling PA+ALSA
Hello, As Sjoerd prompted recently there have been a number of efforts over the years to get some degree of automatic ALSA configuration working when PA is in use. The latest attempt at this is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623002 although for background there is an existing system, which I believe is used in Debian and Ubuntu, which checks to see if the PA daemon is running as part of the alsa config. This is done dynamically thanks to an alsa module and happens every time the alsa config is parsed. IMO, these system have several draw backs. * With the alsa conf module, the system does not handle chases where PA is running remotely and also does not check to see if the sink that will be used (after it's routed) is suspended or not. This actively causes problems with some software that tries to be too clever (case in point being MythTV which can cause deadlocks due to suspending PA when using pcm.default even though it's directed at the alsa-pulse plugin). * The approach linked above is gnome-specific and thus breaks alsa-based auto-spawning from console logins and does not address the issue for anything other than gnome which is not a very good idea IMO. For years I've offered a system in Mandriva (and now Mageia) that has worked very well for me but does not offer per-user flexibility. Ultimately I used the update-alternatives system to define a system-wide "sound profile". At present I have "alsa" and "pulse" as the available profiles, but there could easily be a "jack" or similar profiles created in the future. Ultimately this system controls whether or not to start PA at login. I hack the two start-pulseaudio-* scripts to check to see that the correct sound profile is in use before starting anything. I think other distros do similar things (IIRC Debian/Ubuntu hack out the "pulseaudio --start" call and rely on autospawning to start PA when pactl is called). This takes care of "start at graphical login" cases but autospawning still needs to be dealt with, so we have to switch that on/off in /etc/pulse/client.conf via our drakconf system which is a little more ugly. Anyway, in the interests of trying to standardise approaches, I'm looking for suggestions on how to disable PA in a neat way (i.e. doesn't require editing files if possible) and can work both system wide (i.e. for all users) or on a per-user basis. I would then like to have an alsa config module that uses this config to know whether or not PA should or should not take over the "default" device. All of this should be deterministic (i.e. is should not rely on autospawning or connecting to a running daemon). It should be a preference set by the user. I would propose one of two approaches: 1. Define a new env var PULSE_DISABLE. If this is 1, then PA is disabled, otherwise it's enabled this can then be added to a users profile via /etc/profile.d/ and update-alternatives. or 2. Define a new config file that is honoured by both daemon and client e.g. global.conf: enabled=true. Or is perhaps just a new key in daemon.conf enough, even if the client tries to autospawn, if the daemon is disabled, it will fail as it should. I guess the client code could parse the daemon.conf too to check before autospawning just to save the work? Either way it would be nice to have a simple way to disable PA and write a simple ALSA module to be able to check for that configuration. This would be something that could be adopted cross distro and reduce the fragmentation and in-place file editing. What do people think? 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] Semaphore lockup when using threaded mainloops excessively
'Twas brillig, and Daniel Mack at 22/04/11 10:20 did gyre and gimble:
> On Fri, Apr 22, 2011 at 10:58 AM, Colin Guthrie wrote:
>> 'Twas brillig, and Colin Guthrie at 01/04/11 14:25 did gyre and gimble:
>>> I've pushed this to git master now so that more people can test.
>>
>> I've just be revisiting this one after your pa_poll changes.
>>
>> I tried running two at once and both bailed quite quickly with:
>>
>> Connection (23 of 1000) established.
>> Stream error: Too large
>> Aborted
>>
>>
>> Connection (15 of 1000) established.
>> Stream error: Too large
>> Aborted
>
> That is likely a different issue.
Yeah, it is. I've got a commit in my tree now that reduces the number
for streams to be:
#define NSTREAMS ((PA_MAX_INPUTS_PER_SINK/2) - 1)
This isn't totally safe, but it leaves just a little room for running
two tests at the same time and having a couple other streams sneak in
via regular usage. You OK with that?
>> The abort happened at the same time so both tests aborted at the same
>> time. But I rant it again, and both instances happily ran up to >500
>> connections each.
>>
>>
>> The only (relevant) place I can see this error occurring is in
>> sink-input.c in pa_sink_input_new()
>>
>> But this should only happen when > 32 streams are played on a a sink
>> as each test can use 16 streams I guess there are times when >32 is
>> possible. Perhaps the test should limit it to 15 streams such that this
>> likelyhood is reduced?
>>
>> Anyway a run up to ~500 is pretty good. Is this more or less fixed now
>> do you think?
>
> It is indeed fixed by Lennart in commit 575ba65714 ("memblockq: decode
> unset chunks as NULL chunks again") from last night. We had a little
> session, were able to reproduce it and he fixed it within an hour or
> so :)
Yes, it was that commit that prompted me to reply to this thread
actually! That said, I do not have it applied right now and I still
wasn't able to reproduce the problem even running two connect-stress
tests to the end. Ahh well, I guess it needs more contention or a slower
machine or something (4yr old laptop here tho'!)
Anyway, thanks for confirming it's all fixed now :)
> Another fix for OSX (only) is in my tree now, I'll send a pull request soon.
Cool, no worries :)
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] Semaphore lockup when using threaded mainloops excessively
'Twas brillig, and Colin Guthrie at 01/04/11 14:25 did gyre and gimble: > I've pushed this to git master now so that more people can test. I've just be revisiting this one after your pa_poll changes. I tried running two at once and both bailed quite quickly with: Connection (23 of 1000) established. Stream error: Too large Aborted Connection (15 of 1000) established. Stream error: Too large Aborted The abort happened at the same time so both tests aborted at the same time. But I rant it again, and both instances happily ran up to >500 connections each. The only (relevant) place I can see this error occurring is in sink-input.c in pa_sink_input_new() But this should only happen when > 32 streams are played on a a sink as each test can use 16 streams I guess there are times when >32 is possible. Perhaps the test should limit it to 15 streams such that this likelyhood is reduced? Anyway a run up to ~500 is pretty good. Is this more or less fixed now do you think? 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] glib functions on PA
'Twas brillig, and Margarita Olaya at 21/04/11 17:16 did gyre and gimble: > Hi Tanu, > > On Thu, Apr 21, 2011 at 12:12 AM, Tanu Kaskinen wrote: >> On Thu, 2011-04-21 at 10:13 +0530, Arun Raghavan wrote: >>> On Wed, 2011-04-20 at 23:26 -0500, Margarita Olaya wrote: >>>> Hi, >>>> >>>> The initial implementation of jack detection is using threads and >>>> simple file operations like open, close and read currently I'm looking >>>> into using pa_threads and glib functions. First step It is simple >>>> enough e.g change threads by pa_threads and for file operations I have >>>> >>>> u->fd = g_open(u->device_id, O_RDONLY) >>>> ioch = g_io_channel_unix_new(u->fd); >>>> >>>> then use g_io_channel_read_chars() instead of read. >>>> >>>> I'm wonder if it is the beast approach or I'm missing any PA function >>>> that fits better for this purpose. >>> >>> I'm not aware of any PA code that uses glib for this. module-pipe-sink >>> seems to do most of the things you need so that might serve as a good >>> starting point. >> >> Also, the server side code doesn't use glib for anything - the glib >> dependency has been avoided on purpose. (I don't know or remember the >> details why Lennart has been avoiding glib - is it only to keep the >> amount of dependencies low, or are there some other reasons why PA >> shouldn't use glib.) > > If that is the case, It looks that it is better to keep the simple > file operations, right? Otherwise I'll add a glib dependency. Yes, please use the various pa_ functions already in use for other basic file operations. No glib deps in the core PA or modules (module-gconf is an exception but even it will die away soon - for various values of "soon"). 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] protocol-dbus: Fix some memory management bugs.
'Twas brillig, and Tanu Kaskinen at 21/04/11 06:06 did gyre and gimble: > There were several memory leaks. In addition to those, > pa_dbus_protocol_add_interface() used a string from the > caller as a key to a hashmap, instead of a copy of the > string. This caused trouble when the caller freed the > string while the key was still in use in the hashmap. In my tree now :) Thanks Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC: Filter module loader
'Twas brillig, and Tanu Kaskinen at 21/04/11 05:55 did gyre and gimble:
> On Fri, 2011-04-15 at 20:55 +0200, Colin Guthrie wrote:
>> Also, I had to apply this patch to equalizer-sink to prevent it from
>> crashing the server on unload:
>>
>> diff --git a/src/modules/module-equalizer-sink.c
>> b/src/modules/module-equalizer-sink.c
>> index 0bbb23a..611f7dd 100644
>> --- a/src/modules/module-equalizer-sink.c
>> +++ b/src/modules/module-equalizer-sink.c
>> @@ -1286,7 +1286,7 @@ void pa__done(pa_module*m) {
>>
>> save_state(u);
>>
>> -dbus_done(u);
>> +//dbus_done(u);
>>
>> for(c = 0; c < u->channels; ++c)
>> pa_xfree(u->base_profiles[c]);
>>
>>
>> I mentioned this in another thread... hopefully someone more familiar
>> with dbus can take a look at the underlying issue here :)
>
> I took a look. The issue was that the dbus protocol used a string from
> the equalizer module as a key to an internal hashmap, instead a copy of
> the string. This caused trouble when the equalizer module freed the
> string.
>
> A patch is coming.
Kick ass! Thanks :)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] match: match rule earlier, in SINK_INPUT_NEW
Seems reasonable. In my tree 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] [PATCH] core: Drop empty gaps in the memblockq when playing data from it.
'Twas brillig, and Antti-Ville Jansson at 20/04/11 14:00 did gyre and gimble: > The assert that this patch fixes can be reproduced with e.g. the > following script: > > > SAMPLE_PATH="/usr/share/sounds/alsa/" > SAMPLE="Front_Left" > > pactl remove-sample $SAMPLE 2> /dev/null > pactl upload-sample $SAMPLE_PATH$SAMPLE.wav > > mod1=`pactl load-module module-null-sink sink_name=null1` > mod2=`pactl load-module module-null-sink sink_name=null2` > > pactl play-sample $SAMPLE null1 > > input=`pactl list | grep "Sink Input #" | tail -n 1 | cut -d# -f2` > > echo "Sample $SAMPLE playing as Sink Input #$input" > > pactl move-sink-input $input null2 > pactl move-sink-input $input null1 > > pactl unload-module $mod1 > pactl unload-module $mod2 Thanks for the awesome test case. I'll take a look at this shortly :) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2] call-state-tracker: New component.
'Twas brillig, and Tanu Kaskinen at 20/04/11 11:54 did gyre and gimble: > On Wed, 2011-04-20 at 11:36 +0300, Colin Guthrie wrote: >>> The api object header could be located in >>> src/extra_apis - that would make the api not directly dependent on a >>> particular module. >> >> If the API is not dependant on a particular module, what code calls >> pa_extra_api_register? I'd be happy enough defining this extra API as an >> "IMC" (c.f. IPC) system and thus make it very much tied to modules. > > Hmm... did you get the impression that these apis would not necessarily > be tied to any modules at all? That was not the idea - the apis would be > implemented always by modules, but not necessarily by any particular > module. For example, if there was an api for getting the current call > state, it could be implemented by multiple modules, each of which would > use different logic for determining whether a call is active or not. The > modules would of course conflict with each other, so they could not be > loaded at the same time. This would be handled by > pa_extra_api_register() - only one module could have the api registered > at any given time, the other modules would get an error when they try to > call pa_extra_api_register(). Ahh I get what you mean :) Yeah this all makes sense. Thanks for clarifying :) >>> I've been using the term "extra api" here. I don't think it's the >>> greatest name in the world, but that's the best I could think of. I'd >>> like "extension" more, but that word is already used for other purposes. >> >> Yeah extension is already in use for protocol extensions I guess. >> >> How about pa_imc_*? (for inter-module comms) or is that perhaps too >> cryptic? > > Yeah, it's cryptic, but it's also shorter. And "extra api" isn't an > obvious name either. I'm not sure which I like more. Probably imc. > Regarding function names, they will actually have form pa_imc_manager_* > or pa_extra_api_manager_* if I get to decide... The functions can be > "methods" of either some manager object or pa_core. If they're > implemented directly by pa_core, then the prefix will of course be > pa_core_, but I'd prefer having a separate manager object. OK, so the manager object is separate but kept in the core? Seems fine by me to keep things neatly separated. I thinking of taking a pop at this at some point soon (if you don't beat me to it), so can we decide on the name now? Anyone got any better naming suggestions? pa_imc_manager_* (Pro: short, Con: "Inter Module Comms" cryptic) pa_extra_api_manager_* (Pro: clear, Con: long, Extension vs. Extra which is which and for what purpose?) pa_xapi_manager_* (Pro: short, Con: might be confused with X11) pa_mxapi_manager_* (Pro: quite short, Con: "Module eXtension API" but still quite cryptic) I'm not really blown away by any of them :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] match: don't double free in case of missing table file
'Twas brillig, and Tanu Kaskinen at 20/04/11 12:49 did gyre and gimble: > From: Marc-André Lureau Thanks in my tree 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] [PATCH v2] call-state-tracker: New component.
'Twas brillig, and Tanu Kaskinen at 18/04/11 10:31 did gyre and gimble: > For publishing APIs: > > /* Returns a negative error code if the extra api is already registered. */ > int pa_extra_api_register(const char *name, void *api); > > void pa_extra_api_unregister(const_char *name); > > For consuming APIs: > > /* Returns the currently registered api object, > * or NULL if the api isn't registered right now. */ > void *pa_extra_api_get(const char *name); > > Additionally, there would be a couple of hooks defined for getting > notifications about APIs getting registered and unregistered. That seems sensible. > The "api object" would be a struct with function pointers. The API > provider would create instances of that struct and provide the function > implementation. The API consumer would talk to the provider using those > function pointers. OK, that all seems fine IMO. > The api object header could be located in > src/extra_apis - that would make the api not directly dependent on a > particular module. If the API is not dependant on a particular module, what code calls pa_extra_api_register? I'd be happy enough defining this extra API as an "IMC" (c.f. IPC) system and thus make it very much tied to modules. You could even have a call tracker module that just provides the code you posted earlier with nothing more than a .h file and pa__init and pa__done implementations and make sure this is loaded before any modules that happen to want to use it. > I've been using the term "extra api" here. I don't think it's the > greatest name in the world, but that's the best I could think of. I'd > like "extension" more, but that word is already used for other purposes. Yeah extension is already in use for protocol extensions I guess. How about pa_imc_*? (for inter-module comms) or is that perhaps too cryptic? 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] tests: improve resampler test
Not reviewed much, but sounds sensible from a brief glance. In my tree 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] [PATCH] interpol-test: remove unused include getopt.h
Thanks. Merged. 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 v2] call-state-tracker: New component.
'Twas brillig, and Tanu Kaskinen at 06/04/11 16:23 did gyre and gimble: > On Wed, 2011-04-06 at 14:23 +0100, Colin Guthrie wrote: >> 'Twas brillig, and Tanu Kaskinen at 06/04/11 12:33 did gyre and gimble: >>> +/* This is a shared singleton object, currently used by Meego's voice and >>> + * policy enforcement modules. The purpose of the object is just to >>> maintain >>> + * a boolean state of "call is active" or "call is not active", and to >>> provide >>> + * notification hooks for tracking state changes. So one module will be >>> setting >>> + * the state (the voice module) and one or more modules will follow the >>> state >>> + * through the hooks (the policy enforcement module). */ >> >> Could I use this approach to, for example, extend module-stream-restore >> and module-device-restore, to save particular keys in a stream, or >> device proplist? > > > I don't see any reason why you couldn't. Just realised I quoted totally the wrong bit there I meant to quote: > I'd be interested in implementing at some point (no promises or > timelines) a small framework for making inter-module communication > easier, or at least cleaner (this kind of hacks in pulsecore are > actually very easy to work with, but clean they are not). The main > motivation for this would be ripping out the dbus stuff from > module-stream-restore. The dbus API implementation in > module-stream-restore.c takes about a half of the whole file, which > makes reading the stream-restore code more difficult than it should be. > I'd like to keep the dbus interface implementation in > module-dbus-protocol only. For this to be possible, there would need to > be some way for the modules to talk to each other. It could be solved in > a similar way as this call-state-tracker is done, but I'd prefer a > generic framework that modules could use to publish "extra APIs" that > other modules can then use. Which probably makes my comments seem a little more sane :D Do you have any specific requirements for this inter-module IPC? Do we just need a hook system with random data pointer + userdata? The random data pointer would be specific to the caller/callee pair and the userdata would be as per usual. Anything more specific than that needed? 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] Is this a Pulseaudio bug or a Vala bug? (v2)
'Twas brillig, and Alexander Kurtz at 16/04/11 20:57 did gyre and gimble: > Please merge this into master if you have no objections. Well you know this stuff better than me. I've merged it in my tree now. Sean if you have any objections please shout before I push it (likely tomorrow). Alexander, if possible in future if you could provide git format-patch style diffs, it would make applying them easier for me (and preserving your authorship). It doesn't matter with a couple of simpler patches but for anything larger it would be appreciated! Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] volume: Get more data from volume tests
'Twas brillig, and Arun Raghavan at 17/04/11 11:58 did gyre and gimble: > This makes the volume tests run in two loops and print the minimum, > maximum and standard deviation of readings from the inner loop. This > makes it easier to reason out performance drops (i.e. algorithmic > problems vs. other system issues such as processor contention). Cool. In my tree now. Thanks. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
