Re: [pulseaudio-discuss] My default sound devices are not retained after suspend or reboot
Hi, Can you tell me where is the log file of the debug mode ? I've edited /etc/pulse/daemon.conf and uncommented log-level=debug but I can't find the log file :S Lennart : concerning the card indexes, I'm not sure how to use the control device name, like you said. One of my problem is that I use darkice for recording and broadcasting and its conf file is set up to record hw(1,0). If I don't edit /etc/modprobe.d/alsa-base.conf to fix the sound card order, darkice will record the wrong audio card after a reboot or suspend, because the card order changes. Thx -- Hello, I'm using ubuntu karmic 9.10 with 2 sound cards and a webcam listed below : Next time, please follow this if you have problems with Ubuntu: http://pulseaudio.org/wiki/UbuntuBugs [1] To explain things better, I've made some screenshots : http://box10.pulsradio.com/~pim2/pulseaudiout1.png [2] = my settings for output before suspend (default output = SB0404 == what I want). These settings seem to be retained after suspend or reboot. http://box10.pulsradio.com/~pim2/pulseaudioin1.png [3] = my settings for input before suspend (default input = Audio intern - Line In= == What I want. http://box10.pulsradio.com/~pim2/pulseaudioin2.png [4] = my settings for input after suspend (default input changed to EMU404 - Microphone) This is just an exemple because sometimes after reboot, default input is still Intel but switched to mic-in instead of line-in. Hmm, my educated guess is that some weird suspend script might unload some device/driver on suspend and reload it afterwards. In PA this might cause a different default device to be chosen. You might be able to find out more by enabling debug logging in PA and then checking syslog. (log-level=debug in /etc/pulse/daemon.conf) Maybe it has nothing to do with this problem but I've edited /etc/modprobe.d/alsa-base.conf in order to have always the same order : options snd-emu10k1 index=0 options snd-hda_intel index=1 options snd-usb_audio index=2 That is definitely a bad idea, but probably not the cause of this issue. Stable card indexes are a thing of the past, as it breaks hotplugging. There is also no need for it, as you can use card names (as listed in /proc/asound/cards in the []), or you can use the control device name, such as hw:/dev/snd/by-path/pci-:00:1b.0. Both of which are way more descriptive. Lennart Links: -- [1] http://pulseaudio.org/wiki/UbuntuBugs [2] http://box10.pulsradio.com/~pim2/pulseaudiout1.png [3] http://box10.pulsradio.com/~pim2/pulseaudioin1.png [4] http://box10.pulsradio.com/~pim2/pulseaudioin2.png ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My default sound devices are not retained after suspend or reboot
'Twas brillig, and Sebastien PIMENTA at 11/02/10 09:12 did gyre and gimble: Can you tell me where is the log file of the debug mode ? I've edited /etc/pulse/daemon.conf and uncommented log-level=debug but I can't find the log file :S It's logged to syslog by default. Lennart : concerning the card indexes, I'm not sure how to use the control device name, like you said. One of my problem is that I use darkice for recording and broadcasting and its conf file is set up to record hw(1,0). If I don't edit /etc/modprobe.d/alsa-base.conf to fix the sound card order, darkice will record the wrong audio card after a reboot or suspend, because the card order changes. If you are using PA you should tell all alsa applications to use default this will then record from pulseaudio and you are free to use e.g. pavucontrol to move the recording stream to the device you want. PA will remember this choice for you and always use it after you set it the first time. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] 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 default sound devices are not retained after suspend or reboot
On Thu, 11.02.10 10:12, Sebastien PIMENTA (p...@pulsradio.com) wrote: Your mailer is broken. Lennart : concerning the card indexes, I'm not sure how to use the control device name, like you said. One of my problem is that I use darkice for recording and broadcasting and its conf file is set up to record hw(1,0). If I don't edit /etc/modprobe.d/alsa-base.conf to fix the sound card order, darkice will record the wrong audio card after a reboot or suspend, because the card order changes. Not sure what darkice is. But configuring it to hw:1,0 is a bad idea. You should not use the low-level hw:xxx access mode, unless you really know what you are doing. Use the higher level front:xxx or so. Also, don't specify more than the card identifier, i.e. don't use front:xxx,yyy, use front:xxx. Finally, as I already mentioned, use device names, or control device node paths for opening. Such as: front:Intel, or front:/dev/snd/by-path/pci-:00:1b.0 or suchlike. This will make things much more robust and independant of device index changes. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, 11.02.10 02:01, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble: A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. If you're an admin you'd simply su to the active user and use their access credentials to access their PA system. Also, one could make your admin user member of the audio group, and access the audio device regardless of who's logged in -- but potentially you'll clash with a running PA/audio app which already has the device open. Or, at a higher level you could configure /etc/pulse/default.pa's module-native-protocol-unix to use an auth-group even when running in per-session-mode. All user session should then pick that up and members of that group will always be allowed access. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] hda intel + Line-In + ext. mic
to, 2010-02-11 kello 00:23 +0200, Николай Коротинский kirjoitti: Hi all, I have a laptop Amilo Si 3655 and Ubuntu 9.10 64 I have 2 mic: internal and external. Internal mic work successfully. But external Mic and Line-In work as outputs. Line-In output surround channel. Mic output Center and LFE channels. But sometime I need external Mic and Line-In. How I can change channels on Line-In and Mic? First of all, you will need to use some other profile than surround. So start by switching to stereo output (or stereo duplex) profile in pavucontrol's Configuration tab. If after that Mic or Line-In doesn't work automatically, you will also need to change the source port to Mic or Line-In. Pavucontrol should have a port selection somewhere, probably on the Input Devices tab. I can't check, because pavucontrol crashes my pulseaudio (yes, I should fix or at least properly report that bug...). If you don't have any relevant source ports available for selecting, give the output of pacmd list-sources and amixer -cX (the X in amixer -cX is the sound card name, which can be found inside the square brackets in /proc/asound/cards). -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
2010/2/11 Lennart Poettering lenn...@poettering.net: On Wed, 10.02.10 10:45, Maarten Bosmans (mkbosm...@gmail.com) wrote: The other mode is the system-wide daemon mode. This follows more the traditional unix model of a dedicated pulse user running a daemon to which other users can connect. The system mode is more applicable to an audio server/appliance scenario. I would actually argue that the normal per-session PA logic is much more unixish than anything else. At least on my classic TTYs the bell sound was actually generated in the terminal computer and not on the server computer. And on the old standalone X terminals, it's the very same thing. XBell() is called on the terminal server, and the X terminal generates the sound. That makes sense for the bell. I was referring to the daemon though. In my view the system wide daemon running as a dedicated user (apache, postgres) is an example of the traditional unix model and the per-user daemon (dbus, pulse) is another approach that is gaining a lot of popularity lately on linux distributions. Maarten So, what was true for teletype and X terminals back in the 80s, where the beep sound was played by an app on the terminal server and generated on the terminal client, is still true in the PA world: the audio stream a music player app plays on the terminal server is played back on the terminal client. So, once and for all, if someone complains that PA wasn't unixish enough: first of all, I don't care, and secondly that's a completely bogus statement and is not true. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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] My default sound devices are not retained after suspend or reboot
I've pasted my debug log here : http://pastebin.com/m15aa14a0 The result is kind of chinese for me :) Here is what I did. Before shutting down my system I set up default recording card in pavucontrol to Intel soundcard and Line In. I want my system to fix with this as default. Line 2527 : I open pavucontrol to see if default is still Intel Line In. But I see that it's selected to Intel microphone1. Then I change it back to Line In (line 2585) There are also weird things between lines 550 and 1150 (lots of failed). Thanks :) Le jeudi 11 février 2010 à 02:01 +0100, Lennart Poettering a écrit : On Wed, 10.02.10 18:11, Daniel Chen (seven.st...@gmail.com) wrote: On Wed, Feb 10, 2010 at 5:02 PM, Lennart Poettering lenn...@poettering.net wrote: Hmm, my educated guess is that some weird suspend script might unload some device/driver on suspend and reload it afterwards. In PA this might cause a different default device to be chosen. To clarify, Ubuntu does not unload sound drivers for suspend-to-*. Maybe a sysfs driver bind/unbind? I guess the debug logs should tell us more. Lennart ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
I did that originally. The problem is that I'm building Vinux ISOs on Ubuntu using remastersys, and I'd have to modify ubiquity to change the default user groups. The result is that after isntalling Vinux, Orca doesn't come up talking. Now, I may go modify ubiquity, but I'm more familiar now with PA than ubiquity, and I took a shortcut. Long-term, I'll probably figure out how to change ubiquity to change default user groups. However, since all real users and root will be in the pulse-access group by default, it wont add much in the way of security. Bill On Wed, Feb 10, 2010 at 5:30 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote: Finally, disable group-based authentication to use the sound system. Edit /etc/pulse/system.pa. Find the line that reads: load-module module-native-protocol-unix and change it to read: load-module module-native-protocol-unix auth-anonymous=1 It's much easier and safer to simply add all users to the pulse-access group instead of doing dirty security hacks like this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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
[pulseaudio-discuss] What is latency? And other related questions
This application I am writing a plugin for has a mode where it uses a timer to drive the delivery of sound. At every tick, if some condition is filled, the buffer is filled with data, otherwise the application runs. I managed to write a plugin that successfully delivers audio using the normal pulseaudio API. I check the size of pa_stream_writable_size every tick, and if it is below some threshold, the application runs and produces sound. This threshold right now is some magic number I stumbled upon, but I think it is related to whatever tlength the server automatically gives me. // too high, and there is a big pause before audio begins to play #define milliseconds 30 ... int mixlen = pa_usec_to_bytes (milliseconds * PA_USEC_PER_MSEC, device.spec); ... pa_threaded_mainloop_lock (device.mainloop); free_space = pa_stream_writable_size (device.stream); pa_threaded_mainloop_unlock (device.mainloop); if (free_space mixlen) play (); else write_to_buffer (); I can't write the plugin with the simple API, though, because the only measure I have of the buffer state is pa_simple_get_latency, and this doesn't seem to reflect the state of the sound buffer in the same way that pa_stream_writable_size does. So, I assume I am misunderstanding what latency means. I've never used an audio API before, so I don't have any real understanding of the word, just a sense of it from mailing lists and games. What happens here either there is a large period (~30 seconds to 90 seconds) of silence before audio begins to play fine, or I get bursts of audio (5-10 seconds) followed by very long bursts of silence. I know this is related to prebuffering, but beyond that I am lost. // there isn't any right number to pick here #define MILLISECONDS 180 ... int latency = pa_simple_get_latency if (latency MILLISECONDS) play (); else return 0; So, in short: 1. What is latency? 2. How do the meaning of pa_stream_writable_size and pa_simple_get_latency differ in terms of the fill state of the buffer? 3. Would there be an objection to adding something along the lines of pa_simple_writable_size? Does that even make sense?_ ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My default sound devices are not retained after suspend or reboot
'Twas brillig, and Sebastien Pimenta at 11/02/10 14:07 did gyre and gimble: I've pasted my debug log here : http://pastebin.com/m15aa14a0 The result is kind of chinese for me :) Here is what I did. Before shutting down my system I set up default recording card in pavucontrol to Intel soundcard and Line In. I want my system to fix with this as default. Line 2527 : I open pavucontrol to see if default is still Intel Line In. But I see that it's selected to Intel microphone1. Then I change it back to Line In (line 2585) There are also weird things between lines 550 and 1150 (lots of failed). You're mixing things up here. On the one hand you are telling darkice to use the ALSA harsware directly (which, due to it's design is pretty much all you can do AFAICT) but then you are expecting PA's preferences to in some way help with this. As I explained in a personal mail, if you want to let darkice totally controll your sound input you should select a profile in pavucontrol for that sound card that does not touch audio input at all so that PA does not try and use it for input and you can use raw alsa for that in darkice. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] 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] system-wide daemon
Lennart Poettering wrote: On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) wrote: There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I doubt the too many. Let's conclude that our milages vary, then. The handful of people coming up with this from time to time is fairly minimal, I you allow me to say so. Oh. Most of the people don't complain here. They go googling and find solutions such as stacking PA on top of dmix, using alsa-plughw directly from an application, remove all traces of PA from the system, etc etc, with various degree of success. Sometimes the information is meant for another distro or version, and they end up messing up more than they fix. Anyway, reading this thread has been helpful and I got a few pointers. I'll see if I can sum it up in one page to make the information more accessible. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Lennart Poettering wrote: On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) wrote: But printers are more of a system-wide resource, and for some use cases, so is the soundcard. This is nonsense. I am not sure how your ears are constructed, but on a multiseat system if you want to share a soundcard between two seats, where would you put the speakers so that the two users have the same distance from L and R and they are on the left and the right side? I mean, those users would have to sit on top of each other or detachable ears or something. Detachable ears seems cool, although I'd prefer headphones. Anyway, multiseat wasn't the use case I was talking about here, I was more thinking of the use computer as combined desktop workstation and independent media player for the kitchen use case. We discussed this with a couple of folks long time ago, and decided that some reasources are per-seat resources, and should be configured like that. Those devices are keyboards, mice, screens, sound cards, webcams and a couple of others. the UDEV_ACL=1 property in the udev tree marks most of them. This discussion was mostly done on the udev level btw, it is only indirectly related to PA. Now, in some non-standard cases it might make sense to have the access rules deviate from this default, but those are the exceptions, not the common cases. And that means that you configure it that way, but the default will be the safe, common case, not the dangerous uncommon case. Exactly. BTW, I really do not know why I am even responding, Neither do I. If I knew what makes you respond to some posts and leave others behind, I would have used that knowledge to make you respond to the alsa-plugins patch I suggested earlier [1]. Do you know this Google thing? It's kinda cool, you should try it. Never heard of it. I'll go search for it and see if I find something. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Right, allow every user to listen into all voip calls, You're mixing the use cases up. The soundcards you use to make voip calls, are not necessarily the ones you want to share with other users. Lemme guess, you disable access control to your X11 screen too? There are use cases for that as well, but we can leave them out for now. // David [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006471.html ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] new virtual-sink and virtual-source modules
The patches I am about to post provide two modules that could be of interest to the PulseAudio community. module-virtual-sink is a template for the addition of PCM processing. It's basically based on the LADSPA module, I use it for internal experiments and will enhance it in the future. module-virtual-source is something new. This is the continuation of my earlier work to enable paths that were not possible in PulseAudio. With module-loopback I enabled a source to be played on a sink. Well, this virtual-source module is the missing complement. It wasn't possible until now to mix music with the microphone inputs. Now you can send data to the 'uplink sink' exposed in this module, and it'll be mixed with the inputs and provided to apps by a virtual source element. For example you could be talking with Skype and sharing your music with the remote party. Or send beeps/tones/alerts/DTMF/whatever. Or record a conversation. In addition, this virtual source can be used to add PCM processing on the inputs if you don't care for this mixing capability but want to add EQ, DRC, on a capture path. I played for some time with the idea of adding such a mixing capability for all sources, just like we have monitor sources on all sinks, however you may want to do some processing on the inputs before mixing, and I preferred to implement this mixing capability as an optional feature in a separate module. I did struggle to implement some of the callbacks; this is fairly hairy PulseAudio stuff, you will see a lot of FIXMEs on the code handling latency/state/volume changes. Contributions are welcome to stabilize the code. One known issue: I added some code to wake-up the source when the virtual sink become active, but at some point the suspend-on-idle kicks in and the client gets stuck. I need to find a way to prevent the source from being suspended in that case, even if no client is connected to the source. To enable both modules, just add these lines in default.pa load-module module-virtual-sink sink_name=vsink set-default-source vsink load-module module-virtual-source source_name=vsource uplink_sink=uplink set-default-source vsource You can then test all this with pavucontrol and reroute the data wherever you want. Thanks for your feedback. Cheers, - Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/3] [virtual-sink] Boilerplate virtual sink to add PCM processing
From 78dfa037f869b8fe0613260fdd999693b6305e19 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.boss...@intel.com
Date: Thu, 11 Feb 2010 15:44:11 -0600
Subject: [PATCH 1/3] [virtual-sink] Boilerplate virtual sink to add PCM processing
---
src/modules/module-virtual-sink.c | 635 +
1 files changed, 635 insertions(+), 0 deletions(-)
create mode 100644 src/modules/module-virtual-sink.c
diff --git a/src/modules/module-virtual-sink.c b/src/modules/module-virtual-sink.c
new file mode 100644
index 000..4fe4867
--- /dev/null
+++ b/src/modules/module-virtual-sink.c
@@ -0,0 +1,635 @@
+/***
+This file is part of PulseAudio.
+
+Copyright 2010 Intel Corporation
+Contributor: Pierre-Louis Bossart pierre-louis.boss...@intel.com
+
+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.
+***/
+
+/* TODO: Some plugins cause latency, and some even report it by using a control
+ out port. We don't currently use the latency information. */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include pulse/xmalloc.h
+#include pulse/i18n.h
+
+#include pulsecore/core-error.h
+#include pulsecore/namereg.h
+#include pulsecore/sink.h
+#include pulsecore/module.h
+#include pulsecore/core-util.h
+#include pulsecore/modargs.h
+#include pulsecore/log.h
+#include pulsecore/thread.h
+#include pulsecore/thread-mq.h
+#include pulsecore/rtpoll.h
+#include pulsecore/sample-util.h
+#include pulsecore/ltdl-helper.h
+
+#include module-virtual-sink-symdef.h
+
+PA_MODULE_AUTHOR(Pierre-Louis Bossart);
+PA_MODULE_DESCRIPTION(_(Virtual sink));
+PA_MODULE_VERSION(PACKAGE_VERSION);
+PA_MODULE_LOAD_ONCE(FALSE);
+PA_MODULE_USAGE(
+_(sink_name=name for the sink
+ sink_properties=properties for the sink
+ master=name of sink to filter
+ format=sample format
+ rate=sample rate
+ channels=number of channels
+ channel_map=channel map
+));
+
+#define MEMBLOCKQ_MAXLENGTH (16*1024*1024)
+
+struct userdata {
+pa_module *module;
+
+pa_sink *sink;
+pa_sink_input *sink_input;
+
+pa_memblockq *memblockq;
+
+pa_bool_t auto_desc;
+unsigned channels;
+};
+
+static const char* const valid_modargs[] = {
+sink_name,
+sink_properties,
+master,
+format,
+rate,
+channels,
+channel_map,
+NULL
+};
+
+/* Called from I/O thread context */
+static int sink_process_msg_cb(pa_msgobject *o, int code, void *data, int64_t offset, pa_memchunk *chunk) {
+struct userdata *u = PA_SINK(o)-userdata;
+
+switch (code) {
+
+case PA_SINK_MESSAGE_GET_LATENCY:
+
+/* The sink is _put() before the sink input is, so let's
+ * make sure we don't access it in that time. Also, the
+ * sink input is first shut down, the sink second. */
+if (!PA_SINK_IS_LINKED(u-sink-thread_info.state) ||
+!PA_SINK_INPUT_IS_LINKED(u-sink_input-thread_info.state)) {
+*((pa_usec_t*) data) = 0;
+return 0;
+}
+
+*((pa_usec_t*) data) =
+
+/* Get the latency of the master sink */
+pa_sink_get_latency_within_thread(u-sink_input-sink) +
+
+/* Add the latency internal to our sink input on top */
+pa_bytes_to_usec(pa_memblockq_get_length(u-sink_input-thread_info.render_memblockq), u-sink_input-sink-sample_spec);
+
+return 0;
+}
+
+return pa_sink_process_msg(o, code, data, offset, chunk);
+}
+
+/* Called from main context */
+static int sink_set_state_cb(pa_sink *s, pa_sink_state_t state) {
+struct userdata *u;
+
+pa_sink_assert_ref(s);
+pa_assert_se(u = s-userdata);
+
+if (!PA_SINK_IS_LINKED(state) ||
+!PA_SINK_INPUT_IS_LINKED(pa_sink_input_get_state(u-sink_input)))
+return 0;
+
+pa_sink_input_cork(u-sink_input, state == PA_SINK_SUSPENDED);
+return 0;
+}
+
+/* Called from I/O thread context */
+static void sink_request_rewind_cb(pa_sink *s) {
+struct userdata *u;
+
+pa_sink_assert_ref(s);
+pa_assert_se(u = s-userdata);
+
+if (!PA_SINK_IS_LINKED(u-sink-thread_info.state) ||
+!PA_SINK_INPUT_IS_LINKED(u-sink_input-thread_info.state))
+return;
+
+/* Just hand
[pulseaudio-discuss] [PATCH 2/3] [virtual-source] boilerplate virtual source for PCM processing on inputs.
From 719bea45da05b13f2ad3fc33a00fd09253614f6f Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.boss...@intel.com
Date: Thu, 11 Feb 2010 15:45:35 -0600
Subject: [PATCH 2/3] [virtual-source] boilerplate virtual source for PCM processing on inputs.
---
src/modules/module-virtual-source.c | 771 +++
1 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 src/modules/module-virtual-source.c
diff --git a/src/modules/module-virtual-source.c b/src/modules/module-virtual-source.c
new file mode 100644
index 000..fdf89b0
--- /dev/null
+++ b/src/modules/module-virtual-source.c
@@ -0,0 +1,771 @@
+/***
+This file is part of PulseAudio.
+
+Copyright 2010 Intel Corporation
+Contributor: Pierre-Louis Bossart pierre-louis.boss...@intel.com
+
+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 stdio.h
+#include math.h
+
+#include pulse/xmalloc.h
+#include pulse/i18n.h
+
+#include pulsecore/macro.h
+#include pulsecore/core-error.h
+#include pulsecore/namereg.h
+#include pulsecore/sink.h
+#include pulsecore/module.h
+#include pulsecore/core-rtclock.h
+#include pulsecore/core-util.h
+#include pulsecore/core-error.h
+#include pulsecore/modargs.h
+#include pulsecore/log.h
+#include pulsecore/thread.h
+#include pulsecore/thread-mq.h
+#include pulsecore/rtpoll.h
+#include pulsecore/sample-util.h
+#include pulsecore/ltdl-helper.h
+
+#include module-virtual-source-symdef.h
+
+PA_MODULE_AUTHOR(Pierre-Louis Bossart);
+PA_MODULE_DESCRIPTION(Virtual source);
+PA_MODULE_VERSION(PACKAGE_VERSION);
+PA_MODULE_LOAD_ONCE(FALSE);
+PA_MODULE_USAGE(
+_(source_name=name for the source
+ source_properties=properties for the source
+ master=name of source to filter
+ uplink_sink=name (optional)
+ format=sample format
+ rate=sample rate
+ channels=number of channels
+ channel_map=channel map
+));
+
+#define MEMBLOCKQ_MAXLENGTH (16*1024*1024)
+#define BLOCK_USEC 1000 /* FIXME */
+
+struct userdata {
+pa_module *module;
+
+pa_source *source;
+pa_source_output *source_output;
+
+pa_memblockq *memblockq;
+
+pa_bool_t auto_desc;
+unsigned channels;
+
+/* optional fields for uplink sink */
+pa_sink *sink;
+pa_usec_t block_usec;
+pa_memblockq *sink_memblockq;
+
+};
+
+static const char* const valid_modargs[] = {
+source_name,
+source_properties,
+master,
+uplink_sink,
+format,
+rate,
+channels,
+channel_map,
+NULL
+};
+
+/* Called from I/O thread context */
+static int sink_process_msg_cb(pa_msgobject *o, int code, void *data, int64_t offset, pa_memchunk *chunk) {
+
+switch (code) {
+
+case PA_SINK_MESSAGE_GET_LATENCY:
+
+/* there's no real latency here */
+*((pa_usec_t*) data) = 0;
+
+return 0;
+}
+
+return pa_sink_process_msg(o, code, data, offset, chunk);
+}
+
+/* Called from main context */
+static int sink_set_state_cb(pa_sink *s, pa_sink_state_t state) {
+struct userdata *u;
+
+pa_sink_assert_ref(s);
+pa_assert_se(u = s-userdata);
+
+if (!PA_SINK_IS_LINKED(state)) {
+return 0;
+}
+
+if (state == PA_SINK_RUNNING) {
+/* need to wake-up source if it was suspended */
+pa_source_suspend(u-source, FALSE, PA_SUSPEND_ALL);
+
+/* FIXME: if there's no client connected, the source will suspend
+ and playback will be stuck. You'd want to prevent the source from
+ sleeping when the uplink sink is active; even if the audio is
+ discarded at least the app isn't stuck */
+
+} else {
+/* nothing to do, if the sink becomes idle or suspended let
+ module-suspend-idle handle the sources later */
+}
+
+return 0;
+}
+
+static void sink_update_requested_latency_cb(pa_sink *s) {
+struct userdata *u;
+
+pa_sink_assert_ref(s);
+pa_assert_se(u = s-userdata);
+
+/* FIXME: there's no latency support */
+
+}
+
+
+/* Called from I/O thread context */
+static void sink_request_rewind_cb(pa_sink *s) {
+struct userdata *u;
+
+pa_sink_assert_ref(s);
+pa_assert_se(u = s-userdata);
+
+/* Do
[pulseaudio-discuss] [PATCH 3/3] [Makefile.am] enable virtual-source and virtual-sink
From 0e812456ba0532202b518a66cd35406ba6c964b8 Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart pierre-louis.boss...@intel.com Date: Thu, 11 Feb 2010 15:46:41 -0600 Subject: [PATCH 3/3] [Makefile.am] enable virtual-source and virtual-sink --- src/Makefile.am | 16 ++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 6c0b4d8..3268137 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1027,7 +1027,9 @@ modlibexec_LTLIBRARIES += \ module-position-event-sounds.la \ module-augment-properties.la \ module-cork-music-on-phone.la \ - module-loopback.la + module-loopback.la \ + module-virtual-sink.la \ + module-virtual-source.la # See comment at librtp.la above if !OS_IS_WIN32 @@ -1292,7 +1294,9 @@ SYMDEF_FILES = \ modules/module-cork-music-on-phone-symdef.h \ modules/module-console-kit-symdef.h \ modules/dbus/module-dbus-protocol-symdef.h \ - modules/module-loopback-symdef.h + modules/module-loopback-symdef.h \ + modules/module-virtual-sink-symdef.h \ + modules/module-virtual-source-symdef.h EXTRA_DIST += $(SYMDEF_FILES) BUILT_SOURCES += $(SYMDEF_FILES) @@ -1461,6 +1465,14 @@ module_loopback_la_SOURCES = modules/module-loopback.c module_loopback_la_LDFLAGS = $(MODULE_LDFLAGS) module_loopback_la_LIBADD = $(AM_LIBADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la +module_virtual_sink_la_SOURCES = modules/module-virtual-sink.c +module_virtual_sink_la_LDFLAGS = $(MODULE_LDFLAGS) +module_virtual_sink_la_LIBADD = $(AM_LIBADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la + +module_virtual_source_la_SOURCES = modules/module-virtual-source.c +module_virtual_source_la_LDFLAGS = $(MODULE_LDFLAGS) +module_virtual_source_la_LIBADD = $(AM_LIBADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la + # X11 module_x11_bell_la_SOURCES = modules/x11/module-x11-bell.c -- 1.6.3.3 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
