[pulseaudio-discuss] Does pulseaudio provide any callback mechanism for application on device change?
Does Pulseaudio provide a callback mechanism or any other methods to notify application when audio device changes? I'm working on a policy application that need to know all available audio devices (speaker/mike, headphone, Bluetooth headset, HDMI) and allow user to manually set the default sink/source/port. The application need to be notified on headset/HDMI connection/disconnection. I found there is a API "context_get_sink_info_callback" that can get all available sinks' information. But rather than calling this API periodically to refresh device status, I hope PA can notify my app on the device status change. Great thanks! Mengdong ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Audio output on Bluetooth headset is choppy - PulseAudio at fault?
Hello. Am 19.09.2011 17:43, schrieb Luiz Augusto von Dentz: Hi Alexander, On Mon, Sep 12, 2011 at 12:30 PM, Alexander Skwar wrote: Am 12.09.2011 10:51, schrieb Colin Guthrie: 'Twas brillig, and Alexander Skwar at 12/09/11 07:44 did gyre and gimble: Result: It's just as clippy, as it is with PulseAudio. Keep in mind that the alsa-bluetooth stuff has not has as much focus as PA bluetooth stuff in recent years, but yes, this seems like a valid test. Understood. But if I take out one component (PulseAudio) and replace it with another one (ALSA) and get the same results, then I think that this is a quite strong indication, that this component wasn't involved, or better: causing, in the error/problem at hand. Yet you did say your Android phone does work properly and that afaik is using Linux+BlueZ, now Android does not uses PA and perhaps the SBC parameters are different (iirc bitpool is 32 while PA uses 64 or the max the headset support) but more recent version of PA can adapt the bitpool (you would see in the logs) to try to avoid skipping due to low bandwidth. Btw, do you have anything else connected/using Bluetooth like a mouse? I don't have anything else connected. I could pair my Android phone and transferring files does work. There's no error message shown in this case. It doesn't matter, but I'm not using a builtin receiver, but a USB connected dongle. And sadly I don't have another BT receiver available. Well it matter for us, different controller may have different behavior and we would be happy to make them work. I cannot find a different controller. The one I personally own is "brand new", bought like 2 weeks ago. The other ones I got from colleagues are old (months and even years). They all have the same controller. If you can provide me a different controller, I'm happy to test :-) I think I'm gonna ditch Bluetooth. Too complicated to setup on Linux. :( Oh it's quite simple to setup, just pair the device and provide you're using PA it just works Well… For interesting values of "it just works" ;) It works in Android and N900, which uses PA btw, so it should work for SUSE+KDE as well. "should" ;) the problem is that that it doesn't always work well due to h/w support. Yep. This requires users to give feedback and run tests such that upstream folks can make it better for everyone! Who's upstream now? Bluez? Sent a mail to linux-bluetooth mailing list a few days ago, but haven't received any response so far. I probably missed that, but you got be patient sometimes we are just busy and cannot reply right away, as a matter of fact I have been busy implementing prioritization support (SO_PRIORITY) for Bluetooth sockets. I can be patient. I've now got a Asus headset which uses a USB dongle with some proprietary protocol and this works just perfectly fine. But I'd still like to get the bluetooth combination going. → http://thread.gmane.org/gmane.linux.bluez.kernel/16334 Please don't give up, just have patience and try and get involved :) I'm not a coder. Just a user :) Can't do much more than report bugs or issues and supply details as I see them. Ok you can start by given us the name/model of the headset and Done in my post to the bluez mailinglist at http://thread.gmane.org/gmane.linux.bluez.kernel/16334 ;) I've got an Arctic P311 bluetooth headset[1] and a Hama Nano-Bluetooth-USB-Adapter Version 3.0+EDR Class1 dongle[2]. In "lsusb", the BT dongle is this: Bus 001 Device 048: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) You can find the "lsusb -v" output for this device on pastebin[3]. [1] Arctic P311 -> http://www.arctic.ac/en/p/sound/headsets/35/p311.html [2] Hama BT Dongle -> http://x.co/Zaev --> http://www.hama.de/portal/articleId*28219728/action*2563/searchMode*1/bySearch*49238 [3] lsusb -v -d 0a12:0001 -> http://pastebin.com/xzYSWB9w Alexander -- ↯ Lifestream (Twitter, Blog, …) ↣ http://sup.skwar.me/ ↯ ↯ Chat (Jabber/Google Talk) ↣ a...@skwar.me ; Twitter: @alexs77 ↯ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] create new source from sink + source
On Mon, Sep 19, 2011 at 12:24 PM, Colin Guthrie wrote: > One other option is to do the following. I'm assuming you do not want to > hear the audio produced, hence the use of a null sink. > > load-module module-null-sink sink_name=null > load-module module-combine sink_name=combine > slaves=alsa_output.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-stereo,null > load-module module-loopback sink=null > source=alsa_input.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-mono > > > Then you just set skype to use your null.monitor as for it's recording > sink and the application you want to record should output o the combine > sink. > > This setup ensures that Skype records the product of both what is > playing on the combine sink and the mic. Thanks very much. This worked great! -- - Patrick Donnelly ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Yet another attempt to fight rewinds
On Mon, 2011-09-19 at 17:49 +0200, David Henningsson wrote:
> +if (!pa_ratelimit_test(&s->thread_info.rewind_limit, PA_LOG_DEBUG)) {
> +pa_log_warn("Okay, I'm sick and tired of all this rewinding. I'm
> going to sleep for %lu ms!",
> +s->thread_info.rewind_limit.interval / PA_USEC_PER_MSEC);
> +usleep(s->thread_info.rewind_limit.interval);
> +pa_log_debug("Waking up.");
> +}
The patch seems otherwise ok to me, but I'd prefer the log prints to
include the sink name. When a system has e.g. 6 sinks, all of which may
be in active use at the same time, I really don't like the sink.c
messages that don't tell which sink is in question... Also, instead of
just "waking up", maybe it would be useful to have "waking up; not so
sick and tired anymore" or something else that clearly connects the
wakeup message to the preceding warning.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] create new source from sink + source
'Twas brillig, and Pierre-Louis Bossart at 19/09/11 16:44 did gyre and gimble: >> I'm trying to take the input (source) from a device >> >> alsa_input.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-mono >> >> and combine that with the output being directed to >> >> alsa_output.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-stereo >> >> to form a new "source" from which I can direct to applications, e.g. >> skype. (Basically, I'd like to play some sound over Skype while still >> being able to have conversation.) > > I worked on something similar for the loopback module, it included a new > 'uplink-sink' to mix music/tones with a source. It did not however take the > samples from an actual output, you'd have to use module-combine to play on > both sinks. > If you are interested I can try to find it in my archives (I thought I had > submitted it) One other option is to do the following. I'm assuming you do not want to hear the audio produced, hence the use of a null sink. load-module module-null-sink sink_name=null load-module module-combine sink_name=combine slaves=alsa_output.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-stereo,null load-module module-loopback sink=null source=alsa_input.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-mono Then you just set skype to use your null.monitor as for it's recording sink and the application you want to record should output o the combine sink. This setup ensures that Skype records the product of both what is playing on the combine sink and the mic. Of course this would be a lot easier if there was a module-combine-source, so patches welcome :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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Yet another attempt to fight rewinds
A few Atom users have complained about enternal rewinds since they
upgraded to 0.99.x, see
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/825709
So here's just an idea. As a "last resort", ratelimit the number of
rewinds. If there are more than 10 rewinds in 200 ms, go to sleep for
200 ms. The idea is that during those 200 ms, the client application
will produce enough packets to fill up the buffer enough. Those packets
will then be merged into one, due to an earlier rewind patch that is
already in. The 200 ms sleep might cause a noticable glitch, but
hopefully we get that one glitch only instead of complete brokenness.
But I don't have any such setup here currently, so maybe any of you
could check this patch and see if it works as intended, and has real effect?
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
>From e1a11d045c898b1875532b9a1497c138968bd2ea Mon Sep 17 00:00:00 2001
From: David Henningsson
Date: Mon, 19 Sep 2011 15:54:58 +0200
Subject: [PATCH] Ratelimit rewinds of sinks
Allow max 10 rewinds in 200 ms in order to try to counteract the
eternal rewind issues still seen on low-end CPUs (e g Atom)
BugLink: http://bugs.launchpad.net/bugs/825709
Signed-off-by: David Henningsson
---
src/pulsecore/sink.c |8
src/pulsecore/sink.h |2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index d97fb7e..2d006a5 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -332,6 +332,7 @@ pa_sink* pa_sink_new(
s->thread_info.state = s->state;
s->thread_info.rewind_nbytes = 0;
s->thread_info.rewind_requested = FALSE;
+PA_INIT_RATELIMIT(s->thread_info.rewind_limit, PA_USEC_PER_MSEC * 200, 10); /* max 10 rewinds in 200 ms */
s->thread_info.max_rewind = 0;
s->thread_info.max_request = 0;
s->thread_info.requested_latency_valid = FALSE;
@@ -932,6 +933,13 @@ void pa_sink_process_rewind(pa_sink *s, size_t nbytes) {
if (s->monitor_source && PA_SOURCE_IS_LINKED(s->monitor_source->thread_info.state))
pa_source_process_rewind(s->monitor_source, nbytes);
}
+
+if (!pa_ratelimit_test(&s->thread_info.rewind_limit, PA_LOG_DEBUG)) {
+pa_log_warn("Okay, I'm sick and tired of all this rewinding. I'm going to sleep for %lu ms!",
+s->thread_info.rewind_limit.interval / PA_USEC_PER_MSEC);
+usleep(s->thread_info.rewind_limit.interval);
+pa_log_debug("Waking up.");
+}
}
/* Called from IO thread context */
diff --git a/src/pulsecore/sink.h b/src/pulsecore/sink.h
index 0642dda..8c998e8 100644
--- a/src/pulsecore/sink.h
+++ b/src/pulsecore/sink.h
@@ -47,6 +47,7 @@ typedef struct pa_sink_volume_change pa_sink_volume_change;
#include
#include
#include
+#include
#define PA_MAX_INPUTS_PER_SINK 32
@@ -261,6 +262,7 @@ struct pa_sink {
/* Maximum of what clients requested to rewind in this cycle */
size_t rewind_nbytes;
pa_bool_t rewind_requested;
+pa_ratelimit rewind_limit;
/* Both dynamic and fixed latencies will be clamped to this
* range. */
--
1.7.5.4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] create new source from sink + source
> I'm trying to take the input (source) from a device > > alsa_input.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-mono > > and combine that with the output being directed to > > alsa_output.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-stereo > > to form a new "source" from which I can direct to applications, e.g. > skype. (Basically, I'd like to play some sound over Skype while still > being able to have conversation.) I worked on something similar for the loopback module, it included a new 'uplink-sink' to mix music/tones with a source. It did not however take the samples from an actual output, you'd have to use module-combine to play on both sinks. If you are interested I can try to find it in my archives (I thought I had submitted it) -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Audio output on Bluetooth headset is choppy - PulseAudio at fault?
Hi Alexander, On Mon, Sep 12, 2011 at 12:30 PM, Alexander Skwar wrote: > Am 12.09.2011 10:51, schrieb Colin Guthrie: >> >> 'Twas brillig, and Alexander Skwar at 12/09/11 07:44 did gyre and gimble: > > >>> Result: It's just as clippy, as it is with PulseAudio. >> >> Keep in mind that the alsa-bluetooth stuff has not has as much focus as >> PA bluetooth stuff in recent years, but yes, this seems like a valid test. > > Understood. But if I take out one component (PulseAudio) and replace it > with another one (ALSA) and get the same results, then I think that this > is a quite strong indication, that this component wasn't involved, or > better: causing, in the error/problem at hand. Yet you did say your Android phone does work properly and that afaik is using Linux+BlueZ, now Android does not uses PA and perhaps the SBC parameters are different (iirc bitpool is 32 while PA uses 64 or the max the headset support) but more recent version of PA can adapt the bitpool (you would see in the logs) to try to avoid skipping due to low bandwidth. Btw, do you have anything else connected/using Bluetooth like a mouse? >>> Or do you guys think, that my judgement regardign PulseAudio is a bit >>> premature? >> >> As I said previously, I suspect it's simply due to the receiver built >> into your machine not being supported by bluez as best it could. > > It doesn't matter, but I'm not using a builtin receiver, but a USB > connected dongle. And sadly I don't have another BT receiver available. Well it matter for us, different controller may have different behavior and we would be happy to make them work. >>> I think I'm gonna ditch Bluetooth. Too complicated to setup on Linux. :( >> >> Oh it's quite simple to setup, just pair the device and provide you're >> using PA it just works > > Well… For interesting values of "it just works" ;) It works in Android and N900, which uses PA btw, so it should work for SUSE+KDE as well. >> the problem is that that it doesn't always >> work well due to h/w support. > > Yep. > >> This requires users to give feedback and >> run tests such that upstream folks can make it better for everyone! > > Who's upstream now? Bluez? Sent a mail to linux-bluetooth mailing list > a few days ago, but haven't received any response so far. I probably missed that, but you got be patient sometimes we are just busy and cannot reply right away, as a matter of fact I have been busy implementing prioritization support (SO_PRIORITY) for Bluetooth sockets. > → http://thread.gmane.org/gmane.linux.bluez.kernel/16334 > >> Please don't give up, just have patience and try and get involved :) > > I'm not a coder. Just a user :) Can't do much more than report bugs > or issues and supply details as I see them. Ok you can start by given us the name/model of the headset and Bluetooth dongle, if we find out it is hw related I would try to get it for testing. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] audio source -> pa -> oggenc
--- On Sun, 18/9/11, Colin Guthrie wrote:
> From: Colin Guthrie
> >
> > If I switch with the sound preferences in Gnome, the
> signal appears
> > to head out on /tmp/drainpipe.out. If I hook up
> 'oggenc' on this I
> > get something resembling what I would expect.
>
> I'm not really sure if this is a problem then?
>
> Add in a new sink does pretty much noting until you set
> some (or all)
> apps to use it, so using the Gnome sound prefs is what
> you're expected
> to do. Is this really problem 1?
>
Right - I think problem 1 is my lack of understanding - and you've resolved
that now!
> > PROBLEM 2: the whole task ('java StdAudio' and
> 'oggenc') is over in a
>
> Also note that if you are wanting to make this available to
> others, then
> using the Shoutcast system is a pretty easy way to do this.
> You can push
> straight to shoutcast via GST:
>
> gst-launch-0.10 pulsesrc
> device=alsa_output.pci_8086_27d8_alsa_playback_0.monitor !
> audioconvert
> ! vorbisenc ! oggmux ! shout2send ip=SOMEIP port=8000
> password=hackme
> mount=stream.ogg
>
>
Col - this is exactly what i'm looking for - many thanks!
The weekend disappeared and I may not have a chance to work through your
suggestions for a few more days - but thank for you guidance.
cheers,
Richard
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ubuntu usb "desktop-server" with single user and constant audio feed from mpd
'Twas brillig, and Martin Hamant at 19/09/11 09:38 did gyre and gimble: > Le 16/09/2011 13:35, Colin Guthrie a écrit : >> As a secondary solution for you now, what I'd recommend is the following: >> >> 1. Add your user to the "audio" group. THis means you'll always have >> the right to use the audio devices on your system even when not logged >> in. This comes with some drawbacks (like gdm user not being able to >> access the device when you've got it open with mpd) but in a single >> (real) user system, this isn't too bad. >> >> 2. Run mpd as you, not as an "mpd" user. >> >> >> With this setup things should (mostly) work OK for you. >> >> >> The alternative is to use system wide mode but then you won't get the >> benefits of e.g. SHM and module loading etc. etc. without doing quite a >> few tweaks. > Thank you Colin for answering that fast. > "run mpd as you" implies to not run mpd as a system wide service but > with "manual" start. > Or I would have to modify system wide /etc/mpd.conf with my user: that > would work but would be a little inconsistent... I'm not personally super familiar with mpd config but I believe this is how other users have configured things yes. > In another hand, the user isn't doing anything else that playing audio > files thru mpd, and recording with another app: liquidsoap which runs as > 'liquidsoap' user, which is in the pulse-access group. system sounds > are disabled. Well the pulse-access group is only relevant for a system-wide PA configuration. If you use a system-wide PA, then just add all the users who want access to audio to the pulse-access group (including mpd user) and you should be set. It's generally not our recommended setup due to the following reasons: 1. It prevents client-server usage of SHM memory to avoid copying audio data around. This results in reduced overhead. 2. Due to security reasons, module loading is disabled. This can complicate things such as bluetooth and network device discovery. 3. If there are multiple users, they can spy on each other's audio. > The question is: do I need on the fly module loading in that context ? If this is all the systemd does (play mpd and record via liquidsoap) and you don't really ever login to the machine and use it as e.g. a desktop, then I'd personally setup a single user add it ot the audio group and use it for both mpd and liquidsoap and let it run it's own PA server. However if you do genuinely login to the machine and use it via e.g. X11 or similar, then I'd just set things up as your user. Hope this helps. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ubuntu usb "desktop-server" with single user and constant audio feed from mpd
Le 16/09/2011 13:35, Colin Guthrie a écrit : 'Twas brillig, and Martin Hamant at 16/09/11 10:19 did gyre and gimble: Hi there, I need to setup a server that permanently plays audio by mpd thru pulseaudio. With or without X/gnome started. Means pulseaudio and mpd should start before the graphical part. There will be only one unique user on this box. using Ubuntu 10.04 LTS, pulseaudio daemon starts thanks to the auto-spawn feature, when a gnome user logs in - the issue is, if I start mpd (or any software that use pulseaudio) before gnome, it'll spawn a pulseaudio daemon that belongs to the mpd user. So I get two pulseaudio instances: one which belongs to mpd, the other to my unique system user... But here I need my system user to "supervise" volumes and pulseaudio properties for the whole system ! if I delay mpd startup (by modifying init.d script), all's going well - as it connects to the existing pulseaudio instance. But I don't feel good about that "strap". In a common usage you won't really notice what I describe here, but as I am running this ubuntu from a USB stick, there is a period of time before gnome starts where any program that use pulseaudio will start its own instance. Of course the solution that comes in mind is System Mode. Not good. Second: delays => not good So... What is the best pratice to do that ? Is running mpd as the user which runs the gnome session is a working /or good solution ? Thanks !! OK, so the long term solution is for Ubuntu to switch to systemd (I'm sure they will eventually) and then use the login lingering feature of session management to allow certain user processes to start before the user has logged in (this is specifically designed for situations like sharing files via network with Rygel). This feature could be extended to PA but it does come with some complications. Only the "active" user is allowed access ot audio. When the login manager is present this is GDM (of course Ubunutu are also potentially going to use lightdm which will be broken in all sorts of ways until they start running a full session (which I think was the whole reason to use it in the first place... so don't know what's going on there). Now if the login manager wants to use sounds (e.g. for feedback/earcandy etc.) then it needs to have it's own PA. But, regardless of the above complications, running mpd as a user lingered processes is likely the best route forward. As a secondary solution for you now, what I'd recommend is the following: 1. Add your user to the "audio" group. THis means you'll always have the right to use the audio devices on your system even when not logged in. This comes with some drawbacks (like gdm user not being able to access the device when you've got it open with mpd) but in a single (real) user system, this isn't too bad. 2. Run mpd as you, not as an "mpd" user. With this setup things should (mostly) work OK for you. The alternative is to use system wide mode but then you won't get the benefits of e.g. SHM and module loading etc. etc. without doing quite a few tweaks. Thank you Colin for answering that fast. "run mpd as you" implies to not run mpd as a system wide service but with "manual" start. Or I would have to modify system wide /etc/mpd.conf with my user: that would work but would be a little inconsistent... In another hand, the user isn't doing anything else that playing audio files thru mpd, and recording with another app: liquidsoap which runs as 'liquidsoap' user, which is in the pulse-access group. system sounds are disabled. The question is: do I need on the fly module loading in that context ? Thanks again !! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
