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 guanqun...@intel.com:
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 guanqun...@intel.com
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 guanqun...@intel.com
---
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] [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] 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] 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 gm...@colin.guthr.ie: '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] [PACKAGERS] New dep
'Twas brillig, and Maarten Bosmans at 26/05/11 15:23 did gyre and gimble: 2011/5/16 Colin Guthrie gm...@colin.guthr.ie: 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] 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] 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 Maarten Bosmans at 24/05/11 08:31 did gyre and gimble: 2011/5/23 Quinn Plattel qie...@gmail.com: 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 remote-pulseaudio-client 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] 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 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] 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 change profile of bluetooth headset for different applications?
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] 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
[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
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: module-native-protocol-tcp [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] Jack detection
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
[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] [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
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] 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] 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] [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] 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] 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] 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 mich...@trunner.de
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 lenn...@poettering.net
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 lenn...@poettering.net
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] 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] [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
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] 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] [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] [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] 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
[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] 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] [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 jyri.sa...@nokia.com 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] [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 david.hennings...@canonical.com 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 Sarhajyri.sa...@nokia.com 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 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 jyri.sa...@nokia.com 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] 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] 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 co...@mageia.org
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.
'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] 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 co...@mageia.org
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] 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 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] 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] 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] 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 cguth...@mandriva.org 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 paulepan...@users.sourceforge.net 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 siarhei.siamas...@nokia.com 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] [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] [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] [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] 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] 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] 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] [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] 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] 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] 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] 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-feature 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 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 luiz.dentz-...@nokia.com 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
[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] 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
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] 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 ext-tanu.kaski...@nokia.com
---
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] 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 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] 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] 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 marcandre.lur...@gmail.com --- 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] 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 marcandre.lur...@gmail.com --- 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
[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] 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
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] 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] 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 gm...@colin.guthr.ie 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] 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] 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] [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] 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 marcandre.lur...@gmail.com 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 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] 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] 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] 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] 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] 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
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 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? snip 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] [PATCH] pa_poll(): Simplify detectin of invalid fds in select() emulation mode
'Twas brillig, and Daniel Mack at 15/04/11 11:54 did gyre and gimble: On Thu, Apr 14, 2011 at 7:07 PM, Sean McNamara smc...@gmail.com wrote: Hi, On Thu, Apr 14, 2011 at 9:57 AM, Daniel Mack zon...@gmail.com wrote: On Thu, Apr 14, 2011 at 3:53 PM, Maarten Bosmans mkbosm...@gmail.com wrote: 2011/4/14 Daniel Mack zon...@gmail.com: On Thu, Apr 14, 2011 at 12:46 AM, Maarten Bosmans mkbosm...@gmail.com wrote: return (fd = 0) (fcntl(fd, F_GETFL) != -1); For Windows, both fcntl and F_GETFL are not available. Sigh. Ok, thanks for the feedback. Attached is a new patch which keeps things as they are for Windows but fixes the problem for OS X. That should do it, yes. +#else /* !OS_IS_WINDOWS */ Minor: this is not exactly the symbol used in the #ifdef. Ok. Anyway, isn't the #else only supposed to be used for OSX? In that case the comment should probably say so. No, it's actually really a workaround for Windows as we don't have fcntl() there. (Just curious - the header file does exist, right? I saw it being included by quite a lot of other source files in the PA tree ...) The fcntl.h header *does* exist in MSVC (and in MingW...) but the core Microsoft C Runtime doesn't actually export the fcntl function. On Windows, fcntl header only exists to expose the O_* hexadecimal #defines for the flags for the open() call, which *is* supported. The only fcntl on Windows comes if you use an alternative C library, such as Cygwin's port of newlib or glibc. The native stack doesn't supply it. Ok, thanks for expaining. Colin, can you pick the latest patch from this thread then and apply? Or do you want me to push it and send a pull request? I'll grab it from here but will likely wait until next week as am on my holidays just 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] PulseAudio Developer's Meetup at LAC
'Twas brillig, and Kurt Taylor at 15/04/11 15:06 did gyre and gimble: (Reposting due to this being embedded in an old thread) I have worked out a separate room for us to meet at LAC from 2:00-4:00 pm on Saturday. It's official, we're on the agenda! http://lac.linuxaudio.org/2011/?page=programmode=tableday=2 http://lac.linuxaudio.org/2011/?page=programmode=tableday=2 I need to get back to the organizers with a purpose and agenda. I am proposing the following: PulseAudio Developer's Meetup and Working Session (2-4pm Sat, May 7th, LAC - O'Callaghan Room) - Meetup and brief introductions - Release content and schedule - Technical discussions - Coding breakouts (if time permits) Please respond with comments and suggestions as soon as possible. And, if you haven't already, let me know if you are planning on attending. Great! That's ideal. I think the agenda you have there is fine. I think keeping it relatively free form is fine :) 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: Filter module loader
Hi, Here is my first draft of a filter module to automatically load equalizer and/or echo-cancel modules if automagically and in a manual but convenient way. Essentially you just set the filter.want property on the stream and it should be magically used. It just tries to load a module with the same name as the filter.want value but with module- prepended to it. So if you set filter.want=echo-cancel, it will be automatically loaded and the stream will be moved to it. When the filter sink is no longer needed it will be automatically unloaded. For the automagical bit, a separate module will simply automatically set the filter.want property and set it to echo-cancel for phone streams. If you want to suppress the automatic loading of a filter sink module, just set filter.suppress property equal to the module you want to suppress. e.g. Skype should probably set filter.suppress=echo-cancel. One thing that I've not really considered is how to deal with the fact that echo-cancel is probably only needed when the external mic and speakers are used so there may need to be more smarts added to deal with this, but I'm not really all that clued up on when this should or shouldn't be used. I plan to add a couple buttons next to streams in pavucontrol that toggles manually the equalizer and maybe also echo-cancel too. Comments welcome. I've not really self-reviewed it too much, so probably a couple howlers in there :) (I'll move the prop name defines into the central file that has some common property names before committing) 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/] From 328dc6d61bf96246cb5a0e51106d23b58734b810 Mon Sep 17 00:00:00 2001 From: Colin Guthrie co...@mageia.org Date: Thu, 14 Apr 2011 13:04:03 +0200 Subject: [PATCH 1/2] filter-apply: New module to automatically load filter sinks (and move streams) based on sink-input property hints. This module does not yet deal with modules that need matched inputs/outputs (i.e. echo-cancel) but this will be added in due course. --- src/Makefile.am | 10 +- src/modules/module-filter-apply.c | 400 + 2 files changed, 408 insertions(+), 2 deletions(-) create mode 100644 src/modules/module-filter-apply.c diff --git a/src/Makefile.am b/src/Makefile.am index 38fb569..78076f6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1053,7 +1053,8 @@ modlibexec_LTLIBRARIES += \ module-loopback.la \ module-virtual-sink.la \ module-virtual-source.la \ - module-switch-on-connect.la + module-switch-on-connect.la \ + module-filter-apply.la # See comment at librtp.la above if !OS_IS_WIN32 @@ -1341,7 +1342,8 @@ SYMDEF_FILES = \ module-loopback-symdef.h \ module-virtual-sink-symdef.h \ module-virtual-source-symdef.h \ - module-switch-on-connect-symdef.h + module-switch-on-connect-symdef.h \ + module-filter-apply-symdef.h EXTRA_DIST += $(SYMDEF_FILES) BUILT_SOURCES += $(SYMDEF_FILES) builddirs @@ -1487,6 +1489,10 @@ module_switch_on_connect_la_SOURCES = modules/module-switch-on-connect.c module_switch_on_connect_la_LDFLAGS = $(MODULE_LDFLAGS) module_switch_on_connect_la_LIBADD = $(MODULE_LIBADD) +module_filter_apply_la_SOURCES = modules/module-filter-apply.c +module_filter_apply_la_LDFLAGS = $(MODULE_LDFLAGS) +module_filter_apply_la_LIBADD = $(MODULE_LIBADD) + module_remap_sink_la_SOURCES = modules/module-remap-sink.c module_remap_sink_la_LDFLAGS = $(MODULE_LDFLAGS) module_remap_sink_la_LIBADD = $(MODULE_LIBADD) diff --git a/src/modules/module-filter-apply.c b/src/modules/module-filter-apply.c new file mode 100644 index 000..d4bded5 --- /dev/null +++ b/src/modules/module-filter-apply.c @@ -0,0 +1,400 @@ +/*** + This file is part of PulseAudio. + + Copyright 2011 Colin Guthrie + + PulseAudio is free software; you can redistribute it and/or modify + it under the terms of the GNU Lesser General Public License as published + by the Free Software Foundation; either version 2.1 of the License, + or (at your option) any later version. + + PulseAudio is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with PulseAudio; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + USA. +***/ + +#ifdef HAVE_CONFIG_H +#include config.h +#endif + +#include pulse/timeval.h +#include pulse/rtclock.h + +#include pulsecore/macro.h +#include pulsecore/hashmap.h +#include pulsecore/hook-list.h +#include pulsecore/core.h +#include pulsecore/core-util.h
Re: [pulseaudio-discuss] RFC: Filter module loader
Forgot to say but I have this patch lined up too to make the
filter.want=equalizer-sink stuff work.
Better argument standardisation across the board welcome. Happy for any
suggestions on naming conventions or leaving it as it is.
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 :)
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/]
From a11b6cd5a9c9a713d7e1468151627c2c659835d3 Mon Sep 17 00:00:00 2001
From: Colin Guthrie co...@mageia.org
Date: Thu, 14 Apr 2011 13:00:58 +0200
Subject: [PATCH] equalizer: Use sink_master as the module argument rather than just master.
This brings more uniformity to arguments to match module-echo-cancel
(which needs both sink and source masters, hence the disambiguation).
This will allow other modules to load filters in a more uniform way
in the future without kludges to deal with variation in arguments.
---
src/modules/module-equalizer-sink.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/modules/module-equalizer-sink.c b/src/modules/module-equalizer-sink.c
index bb350c3..0bbb23a 100644
--- a/src/modules/module-equalizer-sink.c
+++ b/src/modules/module-equalizer-sink.c
@@ -79,7 +79,7 @@ PA_MODULE_LOAD_ONCE(FALSE);
PA_MODULE_USAGE(
_(sink_name=name of the sink
sink_properties=properties for the sink
- master=sink to connect to
+ sink_master=sink to connect to
format=sample format
rate=sample rate
channels=number of channels
@@ -133,7 +133,7 @@ struct userdata {
static const char* const valid_modargs[] = {
sink_name,
sink_properties,
-master,
+sink_master,
format,
rate,
channels,
@@ -1088,7 +1088,7 @@ int pa__init(pa_module*m) {
goto fail;
}
-if (!(master = pa_namereg_get(m-core, pa_modargs_get_value(ma, master, NULL), PA_NAMEREG_SINK))) {
+if (!(master = pa_namereg_get(m-core, pa_modargs_get_value(ma, sink_master, NULL), PA_NAMEREG_SINK))) {
pa_log(Master sink not found);
goto fail;
}
--
1.7.4.3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sink-input: Check flat volume with pa_sink_flat_volume_enabled().
'Twas brillig, and Tanu Kaskinen at 15/04/11 17:36 did gyre and gimble: Checking just the flag doesn't work if the sink uses volume sharing, because such sinks never have PA_SINK_FLAT_VOLUME set. 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] pa_poll(): Simplify detectin of invalid fds in select() emulation mode
'Twas brillig, and Colin Guthrie at 15/04/11 17:04 did gyre and gimble: I'll grab it from here but will likely wait until next week as am on my holidays just now Actually it's in my tree now. Will test and push when I get back. 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: Check for readability before reading volume
'Twas brillig, and Arun Raghavan at 12/04/11 09:48 did gyre and gimble: On Tue, 2011-04-12 at 13:11 +0530, Arun Raghavan wrote: This avoids an assert in pa_sink_input_get_volume() when connecting a passthrough stream. Based on Tanu's comments on the previous version of the patch, this one should be correct. Cool. In my tree now. It's a bit strange having an assert for writable right after a check for readable... it should perhaps be less harsh, but we can cross that bridge in the future :) 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 pl bossart at 15/04/11 22:33 did gyre and gimble: I also don't think using a 10s timer is really great to check if the effect is actually needed. If you had a linked list you wouldn't need to do this type of things. let me know if I am making any sense, it's been a long week... The reason for that was to prevent churn on e.g. song changes where streams may disappear for a moment before being replaced (this might not be likely in a practical situation where the same stream is reused, but the reasoning is sound I think). I also agree fully on the general need to make things more unique but IMO that will require a less kludgy solution of using virtual sinks to apply said filters. So I won't be upset if this is a short lived module and it can be replaced later, but hopefully it'll do for the time being :) 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 this a Pulseaudio bug or a Vala bug? (v2)
'Twas brillig, and Alexander Kurtz at 14/04/11 13:52 did gyre and gimble: What do you think? Does the current upstream libpulse.vapi file really work for you w/o modifications? No I seem to get this error too. I'm sure I did test the previous fix, but perhaps not :s I guess you're additional patch with the 32 is needed, but I'll wait for Sean to confirm his thoughts. 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] DBus Protocol + Equalizer sink = explosion
Hi, The current equalizer sink will crash the daemon after loading/unloading due to dbus errors. I've not had a chance to look properly but it relates to the code in dbus_done() in module-equalizer-sink.c as commenting out this function prevents the error (tho' it obviously will leak something or other). I'm guessing that the eq module just needs a little TLC if someone can find some time to look at it? 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] starting multiple pulseaudio instances for the same user
'Twas brillig, and Antoine Martin at 08/04/11 22:20 did gyre and gimble:
Hi,
How can I start multiple copies of pulseaudio for the same $USER, but in
different contexts?
This was working a while back (last year or so - not sure about version
numbers).. but doesn't any more?
My software starts a virtual X server (xpra, vnc..), dbus and a
dedicated pulseaudio server for each session application it launches.
This allows it to redirect the sound (in and out) to/from remote
machines (potentially multiple at once too, some directly, some via
gstreamer+vorbis over ssh) - all this together with the display. see (1)
Each application session gets its own environment and starts
pulseaudio with:
/usr/bin/pulseaudio --start - --disable-shm=true --daemonize=false
--use-pid-file=false --system=false --exit-idle-time=-1 -n
--load=module-suspend-on-idle --load=module-null-sink
--load=module-native-protocol-unix socket=/tmp/pulse-$DISPLAY/native
A single $USER may start dozens of those sessions, each with a different
(virtual) $DISPLAY.
Now, when I start the second instance I can see that it somehow finds
the previous copy (not the one used by my local X11 session)
[pid 3044]
open(/home/antoine/.pulse/70a1ab2a8c9d6cb7625f1706000d-runtime/autospawn.lock,
O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW, 0600) = 5
[pid 3044] fcntl(5, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0,
len=0}
From that point onwards, nothing happens.
Can you please advise on how to restore this functionality?
This is something that is not supported.
PA is, plain and simple, a per-user daemon.
If you want to direct sound from different DISPLAYs to different PA
servers/sinks you can use the PULSE_SERVER and/or PULSE_SINK property on
the X11 root window.
This functionality will get even more difficult to hack round in the
future when XDG_SESSION_DIR is supported (i.e. when it's rolled out via
systemd and supported by PA) so I'd recommend trying to find a way that
works where just one PA daemon per-user is started but appropriate
hacking of the X11 root window properties is done instead to acheive the
same result.
There will ultimately likely always be ways to get the end result you
need tho' :)
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] keys for raop server
'Twas brillig, and Daniel Mack at 11/04/11 14:28 did gyre and gimble: 2011/4/11 Rémi Denis-Courmont r...@remlab.net: On Mon, 11 Apr 2011 12:39:38 +0200, Tomasz Torcz to...@pipebreaker.pl wrote: Some interested in adding server functionality to PA, using attached key? On a side note, I understood (from an Apple AirPort engineer) that there is no need to do the cryptographic stuff to SEND to an ApEx. If it's true, then many hoops in PulseAudio and VLC's RAOP outputs are nasically redumdant. Of course, for an RAOP input, you do need the cryptography (if the remote client asks). I'm not sure how well this fits into PulseAudio though? It does not have a decoder for Apple Lossless, does it? That's true. Streaming from another Mac would also only be interesting for iTunes, as all other applications are not (natively) able to stream to an Airport Express. However, a thing that really could be cool is streaming Music from an iPhone to a computer running PulseAudio. It's possibly something that fits better into VLC or GST etc, (just push a stream to the sound output), although PA does provide a nice framework for listening for it but I think the fact we'd only be able to handle PCM easily (without linking to GST/VLC or similar), it may be better implemented as a separate, but related project? Not really sure to be honest. If the whole crypography overhead can be skipped, in our current ROAP output stuff tho', that would be a bonus. I guess it'll take some trial and error experiments to work that out. 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] rygel mediaserver
'Twas brillig, and Gunnar Aastrand Grimnes at 11/04/11 11:27 did gyre and gimble: Hi all, What is the status of the rygel mediaserver integration atm? In paprefs I can enable upnp/dnla sharing, and the services and stream appears in any players on my network, however, actually playing the stream does not work. I have tried with my WDTV box, a LG BlueRay+DLVA player and simply playing the stream locally with the upnp-inspector. I have also enabled the http-tcp module, as someone said this was needed. The rygel webpage says something about MediaServer spec v1 being deprecated, and that pulse needs to implement v2, but this appears to be done here: http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/module-rygel-media-server.c;hb=ff7acb4d059e21b318b0464ee6fd1785318071cc Does anyone have this working? Any hints for debugging what goes wrong? I think you have to load module-protocol-http as well (not sure I've got the name totally correct). I tried it with my PS3 but never got very far (it defo did try to talk to the http module tho') If you get it working with your WDTV box just by loading http protocol, please report back and I'll tweak paprefs. 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
'Twas brillig, and duportail at 12/04/11 19:20 did gyre and gimble: Op 12-4-2011 18:53, Tanu Kaskinen schreef: On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote: Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportailpo...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. Actually, this situation is supposed to be handled just fine (unless duportail expects both users to be able to use the audio hw simultaneously, which he doesn't mention). If this doesn't work, xubuntu is broken. Some things that can cause this problem: the users are in the audio group, consolekit isn't running or consolekit's udev-acl isn't in use. Maybe xubuntu is broken.I will wait until further releases Make sure that ck-list-sessions reports correctly that only the active user is actually active. Also check the user groups as Tanu reported. But all in all, this *should* be handled correctly (and certainly is on other systems) 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
