Re: [pulseaudio-discuss] Windows binaries
'Twas brillig, and Daniel Mack at 03/03/11 00:58 did gyre and gimble: If you do decide to go the kernel route, make the actual kernel bits as lightweight as possible to be resilient against PA protocol changes and such. Hopefully the kernel bits would be write once, use with any version of PA for a long time to come. It should be completely independent from PA and just function as a loop-trough virtual device which communicates with the userspace via a simple protocol (for sample rate configuration etc) and exports its audio buffers as shared memory. A userspace part would then be in charge to connect this interface to PulseAudio. I personally have no clue about Windows development, and I would like to keep it that way. Any volounteers with appropriate knowledge? :-) Am I right in saying that there was an ESD type thing that did this for the winesd project? I don't know much about it, but if there is one, it's probably a good starting point 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] Skype masking notifications as phone stream
'Twas brillig, and Marko Doda at 03/03/11 07:20 did gyre and gimble: Skype supports pulseaudio, but its kinda buggy, notification sounds get published to pulseaudio as phone streams and the default pulseaudio responds by muting everything else. I solved it by commenting load-module module-cork-music-on-phone Hmm, the notification sounds should be marked as event sounds. I'm pretty sure the Skype folks fixed this a long time ago - are you using an early beta? e.g. here: index: 440 driver: protocol-native.c flags: START_CORKED state: RUNNING sink: 0 alsa_output.pci-_00_1b.0.analog-stereo volume: 0: 76% 0: -7.15 dB balance 0.00 muted: no current latency: 57.46 ms requested latency: 66.00 ms sample spec: s16le 1ch 48000Hz channel map: mono Mono resample method: trivial module: 10 client: 11 Skype properties: window.icon_name = skype application.icon_name = skype media.role = event media.name = Event Sound application.name = Skype native-protocol.peer = UNIX socket client native-protocol.version = 16 application.process.id = 5668 application.process.user = colin application.process.host = jimmy application.process.binary = skype application.language = en_GB.utf8 window.x11.display = :0.0 module-stream-restore.id = sink-input-by-media-role:event 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] Skype masking notifications as phone stream
its version 2.1.0.81 On Thu, Mar 3, 2011 at 10:03 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Marko Doda at 03/03/11 07:20 did gyre and gimble: Skype supports pulseaudio, but its kinda buggy, notification sounds get published to pulseaudio as phone streams and the default pulseaudio responds by muting everything else. I solved it by commenting load-module module-cork-music-on-phone Hmm, the notification sounds should be marked as event sounds. I'm pretty sure the Skype folks fixed this a long time ago - are you using an early beta? e.g. here: index: 440 driver: protocol-native.c flags: START_CORKED state: RUNNING sink: 0 alsa_output.pci-_00_1b.0.analog-stereo volume: 0: 76% 0: -7.15 dB balance 0.00 muted: no current latency: 57.46 ms requested latency: 66.00 ms sample spec: s16le 1ch 48000Hz channel map: mono Mono resample method: trivial module: 10 client: 11 Skype properties: window.icon_name = skype application.icon_name = skype media.role = event media.name = Event Sound application.name = Skype native-protocol.peer = UNIX socket client native-protocol.version = 16 application.process.id = 5668 application.process.user = colin application.process.host = jimmy application.process.binary = skype application.language = en_GB.utf8 window.x11.display = :0.0 module-stream-restore.id = sink-input-by-media-role:event 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 mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Skype masking notifications as phone stream
'Twas brillig, and Marko Doda at 03/03/11 09:10 did gyre and gimble: its version 2.1.0.81 That's the version I have too, but like I say the notification sounds are properly tagged (see my pacmd list-sink-inputs output from the previous mail) FWIW, I do always comment out the x11-cork module and have encouraged distros to do the same and will likely do this upstream too, as it generally causes unexpected results. It's not so much to do with misbehaving applications tho', more the way it works (by simulating key presses) In the upcoming git master release, I'll support things properly in KDE with regards to pausing/resuming, but it wont solve your problem... Not sure what to advise, as, like I say, that's the same version of Skype I have and it's tagging the streams properly. What does your pacmd output look like when a notification is being played? 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] A few pulseadio related issues
'Twas brillig, and Rafał Mużyło at 26/02/11 23:33 did gyre and gimble: Now, as I follow some of the posts on the list, it seems that pavucontrol will get some updates soon. As libglade was declared deprecated by its upstream awhile ago, I'm attaching a patch dropping libglademm dep and a gtkbuilder file (auto-converted by glade). Just a quick note to say I've now applied this patch to pavucontrol. Many thanks :) I made the commit with your details as I only made a tiny modification (dropped the unneeded change to src/Makefile.am and named the glade file to drop the 2 you added). I added a couple post conversion fixes too. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Windows binaries
On Wed, Mar 2, 2011 at 7:58 PM, Daniel Mack zon...@gmail.com wrote: On Mar 2, 2011 9:32 PM, Sean McNamara smc...@gmail.com wrote: On Wed, Mar 2, 2011 at 7:10 PM, Daniel Mack zon...@gmail.com wrote: On Feb 26, 2011 10:00 PM, Sean McNamara smc...@gmail.com wrote: Hi, On Fri, Feb 25, 2011 at 8:28 AM, Maarten Bosmans mkbosm...@gmail.com wrote: As the patches that make it possible to build pulse on win32 should land in master any moment now, I thought it would be a good time to make the binaries available for download. This is amazing work! I'm able to play audio from Ubuntu to Win32 over a gigabit ethernet crossover cable (to spare the latency of the router), using Ubuntu 11.04 on the Linux side. No dropouts. I remember doing this a long time ago, but it wasn't nearly as reliable or robust. I've tested several simultaneous streams, with no detectable problems, with Synergy desktop sharing going over the same connection. Interesting! As I'm currently working on a port to Mac OS X, I'm curious if anyone has plans to add a way to redirect audio from native Windows applications (ASIO, WDM) to PulseAudio. I believe it would be mandatory to hack a kernel driver to provide a virtual sound card for sinks and sources, just like on OS X. Or you can use the fact that module-waveout supports a source, coupled with a pre-existing Windows device driver that provides a loopback, to do something like this: But such a driver doesn't exist yet, correct? Such a driver does exist. First of all, if you have the right sound card + platform combination, you get a loopback capture channel for free as part of installing your sound card's drivers -- no further effort needed. This is soundcard-dependent. I hear that Creative SoundBlaster based cards (both the really old ones, and the current ones) have the best chance of providing this. In case you don't have that, you can use the proprietary, commercial software Virtual Audio Cable. It is digitally signed and works on all versions of Windows starting with 32-bit XP, all the way up to 64-bit Windows 7. The cost is typical for proprietary Windows software, at $50 USD -- so not too cheap but not too expensive. Since you're already running Windows (the generic you, as in, any interested user), you should already be used to paying for proprietary software, and so, this should be no problem. :) A FOSS version of Virtual Audio Cable would be welcome, but I don't think you would get that digitally signed by Microsoft WHQL. I heard a rumor (possibly false) that lack of publicly available source code is a criterion for WHQL acceptance, for security [through obscurity?] reasons. It has to be signed for the driver to load at all on 64-bit Vista / 7, unless you boot your system into test mode, which I can't recommend for security and stability reasons. Test mode is also either tedious (you have to do it every time you boot) or risky (install untrusted third-party software that automates booting from test mode for you). And IMHO, 64-bit Vista/7 are the flagship OS products of Microsoft right now; 32-bit is basically deprecated. Windows audio app (DSound, WinMM, WaveOut, KS, WASAPI-Shared, etc.) == playback of device which supports loopback Loopback comes out of kernel as a capture channel == captured in PA server on Windows via module-waveout == module-loopback == module-tunnel-sink == (network) == remote PA server on another computer. Admittedly this is less efficient, but mucking around in the Windows kernel carries around a lot more baggage than with other kernels. You have to get it digitally signed if you want to run it on 64-bit OSes. You have to test it to make sure it works on Windows XP 32-bit, XP 64-bit, Vista/7 32-bit and Vista/7 64-bit. And 99.% of Windows users have no idea how to build kernel code (nor do they have the tools to do so), so you have to ship binaries. All in all, a really ugly task that will be difficult to maintain. I know, Windows is a total disaster, especially in kernel space. We had so much trouble with driver development already, it's unbelievable. However, it would maybe suffice to just support some versions of Windows, and skip the legacy. In that case, you could probably write one driver for Vista and Windows 7, 32-bit and 64-bit, without major code changes between 32/64 and Vista/7. The audio driver stuff changed sufficiently with Vista that a separate driver is needed to support XP in any fashion. Throwing out XP would certainly simplify things, but you still have a big task ahead :) If you do decide to go the kernel route, make the actual kernel bits as lightweight as possible to be resilient against PA protocol changes and such. Hopefully the kernel bits would be write once, use with any version of PA for a long time to come. It should be completely independent from PA and just function as a loop-trough virtual device which communicates with the userspace
Re: [pulseaudio-discuss] A few pulseadio related issues
On Thu, Mar 03, 2011 at 02:56:27PM +, Colin Guthrie wrote: Just a quick note to say I've now applied this patch to pavucontrol. Many thanks :) I made the commit with your details as I only made a tiny modification (dropped the unneeded change to src/Makefile.am and named the glade file to drop the 2 you added). I added a couple post conversion fixes too. Thanks, though a minor clarification: - the rename was simply for my testing, I haven't removed it from the patch only by mistake - CXXFLAGS - CPPFLAGS, while technically unneeded, are stylewise more correct, just see automake's info page - even though pkg-config names them CFLAGS, nearly every time (that is: for nearly every package (at least the ones, I came across), that uses pkg-config) they're just CPPFLAGS ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] unused check_required function in modules/alsa/alsa-mixer.c
I intended to catch diwic on IRC, but didn't see him the last couple of days, so in order not to forget, here is my question to the list. In this commit some stuff got shuffled around in alsa-mixer http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=b0f72311 With the result that the check_required function is now unused (or more precise: only used by itself). This is probably incorrect. David, can you explain/fix? Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio passthrough samplerate
Hey, I've been hacking on xbmc - pulseaudio passthrough and I'm getting there a little bit at a time. It seems that at the moment that if the daemon.conf default-sample-rate is set to 44100 then all I can passthrough is 44100 and if it's 48000 all that works are 48000 samples. Is that a limitation in the current pulse implementation? I expected that this would be set from the pa_sample_spec, but that seems to be ignored currently. I'm using paplay --rate ? --raw --passthrough for testing. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Skype masking notifications as phone stream
i have same output as yours, one helpfull guy told me about the problems with streams, i guess thats not the issue, anyway i commented the module and now everything works just fine :). tnx a lot On Thu, Mar 3, 2011 at 10:55 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Marko Doda at 03/03/11 09:10 did gyre and gimble: its version 2.1.0.81 That's the version I have too, but like I say the notification sounds are properly tagged (see my pacmd list-sink-inputs output from the previous mail) FWIW, I do always comment out the x11-cork module and have encouraged distros to do the same and will likely do this upstream too, as it generally causes unexpected results. It's not so much to do with misbehaving applications tho', more the way it works (by simulating key presses) In the upcoming git master release, I'll support things properly in KDE with regards to pausing/resuming, but it wont solve your problem... Not sure what to advise, as, like I say, that's the same version of Skype I have and it's tagging the streams properly. What does your pacmd output look like when a notification is being played? 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 mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Configuring PulseAudio to use ALSA PCM plugin
On Wed, 2011-03-02 at 18:16 -0800, Ben C wrote:
Hello, I'm trying to configure PulseAudio to use an ALSA PCM plugin in the
audio
chain.
PulseAudio as been configured with:
load-module module-alsa-sink device=my_sink
And ALSA has been configured with:
pcm.my_sink {
type my_pcm_plugin
slave.pcm hw:0,0
}
However, my_sink seems to get hogged, and be considered busy. I had to
configure dmix in order for this setup to work. Is that normal? Am I
configuring
something incorrectly? I would assume that to PulseAudio, these ALSA output
devices are the same, whether it's a physical device or a virtual one. But
when
using the default configuration (and my_pcm_plugin is not in the chain),
dmix
isn't necessary.
Thanks for your help.
Do you have another line in your default.pa loading
module-alsa-card/sink before the line above? module-udev-detect or
similar?
The modules that are loaded before the line are:
module-device-restore
module-stream-restore
module-card-restore
module-augment-properties
After the alsa sink, module-udev-detect is loaded. Module-alsa-card isn't
loaded
by the configuration file, but it's there, maybe it's loaded by
module-udev-detect.
Please let me know if you need any other information. Thanks!
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio passthrough samplerate
It seems that at the moment that if the daemon.conf default-sample-rate is set to 44100 then all I can passthrough is 44100 and if it's 48000 all that works are 48000 samples. Is that a limitation in the current pulse implementation? I expected that this would be set from the pa_sample_spec, but that seems to be ignored currently. I'm using paplay --rate ? --raw --passthrough for testing. Yes it's a know limitation I mentioned in my previous emails. Somehow we will need to reconfigure the passthrough sink frequency. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] pulseaudio xbmc passthrough success
Yahoo! I've got pulseaudio xbmc passthrough working. I've rolled it together with a previously windows c++ library called Ac3Filter. I've been tweeking up Ac3Filter quite a bit. I'm using the Ac3Filter library to Mux spdif. It was a well written library/tools that was relatively easy to get ported to linux. I'm watching Avatar in wonderful DTS surround sound now. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio xbmc passthrough success
Forgot to mention. I'm getting Hi-def video/audio and only using 8% cpu. That's just awesome. Vdpau is handling the video decode. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] allow conditionals in config input files like default.pa.in
It would be nice to have the ability to use @if HAVE_FEATURE@ in the
configuration file templates. You could see it either as an extension
of the current @VARIABLE@ replacement or as a compile-time variant of
.ifexists.
Incidentally, does anybody know why these files are currently
generated in the Makefile using sed, instead of being included in
AC_CONFIG_FILES?
Adding that ability has several advantages:
- The default.pa.in and default.pa.win32 files can be merged.
- The BSDs still use module-hal-detect, so it can be included in
default.pa without littering it with [.ifexists module-hal-detect\n
load-module module-hal-detect\n .endif] for Linux users, so they
cannot be confused by it.
- And thirdly, if sys/resource.h is not found the daemon does not
understand the --rlimit-* options, so in that case those lines should
be omitted from daemon.conf.
Would this be a good change, or are we then preprocessing at too many levels?
I propose to implement it by using awk, instead of where now sed is
used in the Makefiles. Below is a very rude patch, to give an idea.
Obviously the variable initialisation in the BEGIN section of the awk
script should depend on the results of the configure checks, either by
using awk -v VAR=$(VAR) in the Makefile or letting configure do the
substitution in the script itself.
Maarten
diff --git a/src/Makefile.am b/src/Makefile.am
index 24e2f82..4c2be0c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1875,21 +1875,10 @@ start-pulseaudio-kde:
daemon/start-pulseaudio-kde.in Makefile
client.conf: pulse/client.conf.in Makefile
sed -e 's,@PA_BINARY\@,$(PA_BINARY),g' $ $@
-if OS_IS_WIN32
-default.pa: daemon/default.pa.win32
- cp $ $@
-system.pa: daemon/default.pa.win32
- cp $ $@
-else
default.pa: daemon/default.pa.in Makefile
- sed -e 's,@PA_BINARY\@,$(PA_BINARY),g' \
--e 's,@PA_DLSEARCHPATH\@,$(modlibexecdir),g' \
- -e 's,@PA_SOEXT\@,.so,g' $ $@
+ awk -f script.awk $ $@
system.pa: daemon/system.pa.in Makefile
- sed -e 's,@PA_BINARY\@,$(PA_BINARY),g' \
--e 's,@PA_DLSEARCHPATH\@,$(modlibexecdir),g' \
- -e 's,@PA_SOEXT\@,.so,g' $ $@
-endif
+ awk -f script.awk $ $@
daemon.conf: daemon/daemon.conf.in Makefile
sed -e 's,@PA_DLSEARCHPATH\@,$(modlibexecdir),g' \
diff --git a/src/daemon/default.pa.in b/src/daemon/default.pa.in
index ace0f09..8f660d7 100755
--- a/src/daemon/default.pa.in
+++ b/src/daemon/default.pa.in
@@ -22,10 +22,10 @@
.nofail
### Load something into the sample cache
-#load-sample-lazy x11-bell /usr/share/sounds/gtk-events/activate.wav
-#load-sample-lazy pulse-hotplug /usr/share/sounds/startup3.wav
-#load-sample-lazy pulse-coldplug /usr/share/sounds/startup3.wav
-#load-sample-lazy pulse-access /usr/share/sounds/generic.wav
+#load-sample-lazy x11-bell @PA_DATA_DIR@/sounds/gtk-events/activate.wav
+#load-sample-lazy pulse-hotplug @PA_DATA_DIR@/sounds/startup3.wav
+#load-sample-lazy pulse-coldplug @PA_DATA_DIR@/sounds/startup3.wav
+#load-sample-lazy pulse-access @PA_DATA_DIR@/sounds/generic.wav
.fail
@@ -41,6 +41,10 @@ load-module module-augment-properties
### Load audio drivers statically (it's probably better to not load
### these drivers manually, but instead use module-hal-detect --
### see below -- for doing this automatically)
+@if OS_IS_WIN32@
+load-module module-waveout sink_name=output
+load-module module-waveout source_name=input
+@endif@
#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-oss device=/dev/dsp sink_name=output source_name=input
@@ -49,6 +53,11 @@ load-module module-augment-properties
#load-module module-pipe-sink
### Automatically load driver modules depending on the hardware available
+@if HAVE_HAL@
+.ifexists module-hal-detect@PA_SOEXT@
+load-module module-hal-detect
+.endif
+@endif@
.ifexists module-udev-detect@PA_SOEXT@
load-module module-udev-detect
.else
diff --git a/src/script.awk b/src/script.awk
new file mode 100644
index 000..ed141f1
--- /dev/null
+++ b/src/script.awk
@@ -0,0 +1,24 @@
+BEGIN {
+ HAVE_HAL=0
+ OS_IS_WIN32=1
+ PA_DLSEARCHPATH=/usr/lib/pulse/modules
+ PA_DATA_DIR=/usr/share
+ PA_BINARY=pulseaudio
+ PA_SOEXT=.so
+
+ printline = 1
+}
+{
+ gsub(/@PA_DLSEARCHPATH@/, PA_DLSEARCHPATH)
+ gsub(/@PA_DATA_DIR@/, PA_DATA_DIR)
+ gsub(/@PA_BINARY@/, PA_BINARY)
+ gsub(/@PA_SOEXT@/, PA_SOEXT)
+ if (/@if [A-Z0-9_]+@/) {
+if (/@if HAVE_HAL@/ !HAVE_HAL) printline = 0
+if (/@if OS_IS_WIN32@/ !OS_IS_WIN32) printline = 0
+ }
+ else if (/@endif@/)
+printline = 1
+ else if (printline)
+print $0
+}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] unused check_required function in modules/alsa/alsa-mixer.c
On 2011-03-03 17:54, Maarten Bosmans wrote: I intended to catch diwic on IRC, but didn't see him the last couple of days, so in order not to forget, here is my question to the list. In this commit some stuff got shuffled around in alsa-mixer http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=b0f72311 With the result that the check_required function is now unused (or more precise: only used by itself). This is probably incorrect. David, can you explain/fix? Hmm, in my patch as posted months ago, the call to check_required was moved inside the element_probe function only, not moved from element_probe to check_required. Colin, can anything have gone wrong when you merged it? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Tue, 2011-03-01 at 15:20 +, Liam Girdwood wrote: On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote: What if one card has two playback devices - one for handsfree and one for a headset - and I want to play a ringtone to both simultaneously? What if one card has two playback devices - one for handset and one for TV-out - and I want to play music to the TV while a call is ongoing, and the call audio to the handset? I'm not saying that this kind of hardware exists, or that anyone actually wants to play music while having a call, but it would be nice if a solution would be found that would support also these cases. Hmm, I found now use-case.h via the link that you gave. That, together with your explanations, is making this more clear. Apparently those cases that I mentioned are supported by UCM via modifiers. So, if I've understood correctly, UCM dictates that there is always exactly one verb (main stream) and exactly one device (main device) selected per card. Additional streams and devices can be used by activating any number of modifiers. UCM supports between 0..n active devices per verb. e.g. it is possible to enable both the headphone device and speaker device at the same time. Right, I missed this. But these multiple devices must share the PCM device, because there can be only one PCM device associated with a verb. For example, if I wanted to play a ringtone to both the handsfree speaker and to a headset, I could select verb ringtone and device speaker, and then I'd activate modifier headset-ringtone, after which I could open the headset device in addition to the speaker device. In pulseaudio this would map to two sinks, and I'd use module-combine to play the ringtone to both. For another example, if I wanted to hear to music from the TV while talking to the phone, I could select the Voice Call verb and the Handset device, and then I'd activate modifier tv-music, after which I could open the TV-out device in addition to the handset device. Or since I probably was listening to the music before the call started, maybe I'd continue with the HiFi+TV-out combination and use a modifier for the call audio. My proposal is that profiles are generated for each available verb +device pair. I think the concept of a profile is going to need to be altered in some way to accommodate modifiers, because activating a modifier can enable a new PCM device (not always, though). A new PCM device means a new sink or source, but creating such sink or source needs to be possible without tearing down and recreating other sinks and sources of the profile, and that's not possible with current profiles. I propose that profiles stay as they are, with the difference that each sink and source of the profile can be enabled and disabled independently. The configuration defines which sinks and sources are activated by default. module-card-restore would remember user choices, though, so the defaults would be relevant only when the user hasn't done any changes, or when module-card-restore isn't used. (I don't think we actually need to have any UI for enabling and disabling the devices in a profile, at least initially, so for non-UCM configurations there wouldn't need to be any observable changes in behavior.) So, the verb+device pair would define the default sink and/or source that are always created when the profile is activated, and modifiers that have different PCM device than the device of the main use case would create additional devices to the profile. Modifiers that have the same PCM device as the main use case would add ports to the main use case sink and/or source. And if the main use case uses for example pcm0 and two modifiers use pcm2, then the two modifiers are exposed as ports on the sink of pcm2. If we have verb+device pairs, how would we enable the Music verb and play to more than one device at the same time ? With modifiers that enable more devices. But yeah, since UCM supports defining multiple devices per verb as long as they use the same PCM device, it would be good if Pulseaudio would support this kind of configuration too. So, I hereby change my proposal: there would be one profile per verb, not per verb+device. This is then the same approach that Margarita started with :) If a verb has multiple devices defined for it, ports would be generated for the sink/source for each possible combination of those devices. Otherwise my proposal stays the same: modifiers are modeled using mappings or ports, depending on whether the modifier PCM device is different or the same that is already associated with some already existing mapping in the profile. Profiles will have to be changed so that mappings can be activated independently, without interrupting streams going to already activated mappings. -- Tanu ___ pulseaudio-discuss
[pulseaudio-discuss] Problem in running locally compiled pulse utility programs
Hi, I run Ubuntu 9.10, which by default has pulseaudio and utilities like pactl, pacmd. I downloaded pulseaudio source tarball http://0pointer.de/lennart/projects/pulseaudio/pulseaudio-0.9.22.tar.gz and extracted it, ran configure script, compiled it and tried to run the locally built pactl utility. While running pactl(the one which I built), it gave me Connection failure: Connection refused Error. But the default 'pactl' utility which is already present in /usr/bin/ works fine. $ ./configure --prefix=tmpdir $ make $ make install $ cd tmpdir $ ./bin/pactl stat Connection failure: Connection refused Can someone tell me, what am I missing? Why is the locally built pactl doesn't work? while the default /usr/bin/pactl works fine. Are these utility programs coupled to 'pulseaudio' along with which it is compiled? Thanks in advance. -- Regards, ssrk ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Wed, 2011-03-02 at 20:52 -0600, Margarita Olaya wrote: On Tue, Mar 1, 2011 at 9:20 AM, Liam Girdwood l...@slimlogic.co.uk wrote: On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote: On Sun, 2011-02-27 at 22:53 -0600, Margarita Olaya wrote: Hi Tanu, On Sat, Feb 26, 2011 at 2:07 AM, Tanu Kaskinen ta...@iki.fi wrote: On Fri, 2011-02-25 at 14:09 -0600, Margarita Olaya wrote: Make sense. But I am not sure the profiles as defined today in PulseAudio can work with modifiers. What we discussed yesterday is that when a profile is selected then you would set the UCM verb and know about all possible sinks. We would need additional logic to have profile modifiers, or we would need extra profiles to represent all possible combinations (speech, speech+tone, speech+music, etc). The initial idea is to use the UCM data to generate the card profiles, then when the stream is open PA will use his method to select the profile and set the verb. e.g when UCM is present: profile = verb. In the UCM module the data is store in a proplist per verb, the proplist has the following info: PA_PROP_UCM_SINK - PlaybackPCM PA_PROP_UCM_SOURCE - CapturePCM PA_PROP_UCM_PLAYBACK_VOLUME - PlaybackVolume PA_PROP_UCM_PLAYBACK_SWITCH - PlaybackSwitch PA_PROP_UCM_CAPTURE_VOLUME - CaptureVolume PA_PROP_UCM_CAPTURE_SWITCH - CaptureSwitch PA_PROP_UCM_QOS - TQ This means that there's only one sink and source per verb. That's probably ok, but if profile = verb, then this also means that there's only one sink and source per profile. Yes, this correct. What if one card has two playback devices - one for handsfree and one for a headset - and I want to play a ringtone to both simultaneously? What if one card has two playback devices - one for handset and one for TV-out - and I want to play music to the TV while a call is ongoing, and the call audio to the handset? I'm not saying that this kind of hardware exists, or that anyone actually wants to play music while having a call, but it would be nice if a solution would be found that would support also these cases. Hmm, I found now use-case.h via the link that you gave. That, together with your explanations, is making this more clear. Apparently those cases that I mentioned are supported by UCM via modifiers. So, if I've understood correctly, UCM dictates that there is always exactly one verb (main stream) and exactly one device (main device) selected per card. Additional streams and devices can be used by activating any number of modifiers. UCM supports between 0..n active devices per verb. e.g. it is possible to enable both the headphone device and speaker device at the same time. For example, if I wanted to play a ringtone to both the handsfree speaker and to a headset, I could select verb ringtone and device speaker, and then I'd activate modifier headset-ringtone, after which I could open the headset device in addition to the speaker device. In pulseaudio this would map to two sinks, and I'd use module-combine to play the ringtone to both. For another example, if I wanted to hear to music from the TV while talking to the phone, I could select the Voice Call verb and the Handset device, and then I'd activate modifier tv-music, after which I could open the TV-out device in addition to the handset device. Or since I probably was listening to the music before the call started, maybe I'd continue with the HiFi+TV-out combination and use a modifier for the call audio. My proposal is that profiles are generated for each available verb +device pair. I think the concept of a profile is going to need to be altered in some way to accommodate modifiers, because activating a modifier can enable a new PCM device (not always, though). A new PCM device means a new sink or source, but creating such sink or source needs to be possible without tearing down and recreating other sinks and sources of the profile, and that's not possible with current profiles. I propose that profiles stay as they are, with the difference that each sink and source of the profile can be enabled and disabled independently. The configuration defines which sinks and sources are activated by default. module-card-restore would remember user choices, though, so the defaults would be relevant only when the user hasn't done any changes, or when module-card-restore isn't used. (I don't think we actually need to have any UI for enabling and disabling the devices in a profile, at least initially, so for non-UCM configurations there wouldn't need to be any observable changes in behavior.) The list of profiles and mappings are populated using the pa_profile_set_new @pa__init, after the list is built the profiles are
