Re: [pulseaudio-discuss] [RFC PATCH] softvolume: implement fast volume translation
On Tue, Oct 18, 2011 at 06:10:06PM +0800, Maarten Bosmans wrote: > > 2011/10/18 Wang Xingchao : > >> if all channels have same volume setting, use fast way to > >> do volume change. this patch intended to work for two formats: > >> s16ne/s16re. > > I did some work to optimize svolume already, see my branch on github: > https://github.com/mkbosmans/pulseaudio/compare/master...orcify > > After a few pending patches that I have already sent to the list are > pulled, I plan to submit this branch in parts. (the branch needs to be > rebased after the pending patches are committed) > > For testing correctness of your volume implementation (and > performance, as Tanu suggested) you can use the svolume-test program > added in this commit: > https://github.com/mkbosmans/pulseaudio/commit/cf0c5c9ad47ba0434b0518ca79ca802d0e62153a > > The Orc svolume implementation currently only handles 1ch s16ne (the > orcify branch also adds 1ch float), so I added a similar test for > identical channel volumes for the Orc case: > https://github.com/mkbosmans/pulseaudio/commit/8659d08f22ccaba0c1ca18c0b29744318bf4fe08 > I like that way (only using one extra variable) a bit better than > yours (with both same_vol and fast_vol added), but that is not really > important. Hi Maarten, Thanks for your nice work, I'll take a look. According to my test here, it seems soft volume processing doesn't cost CPU usage too much, instead, it's the resampling that takes much CPU usage. e.g. one sink input, resampler of speex-float-3 is used, the general CPU usage is about 4%, when resampler of 'copy' is used (of course, in this case, the same format of sink input and sink should match), it drops to less than 1%. So should we optimize resampler a little harder? > > 2011/10/18 Wang Xingchao : > > Hi all, > > > > I didnot touch much formats optermization, only for most used > > s16nr/re, please help review whether the idea is acceptable. If so, i > > will take the responsbility for all formats. > > I'd say only float32ne is another candidate. > > Maarten > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] fix two warnings in utils/padsp.c
CC libpulsedsp_la-padsp.lo
utils/padsp.c:1524:5: warning: no previous prototype for '__open_2'
[-Wmissing-prototypes]
utils/padsp.c:2560:5: warning: no previous prototype for '__open64_2'
[-Wmissing-prototypes]
---
src/utils/padsp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/utils/padsp.c b/src/utils/padsp.c
index a8bc8d2..414ebe4 100644
--- a/src/utils/padsp.c
+++ b/src/utils/padsp.c
@@ -64,6 +64,9 @@
#undef open
#undef open64
+int __open_2(const char *filename, int flags);
+int __open64_2(const char *filename, int flags);
+
typedef enum {
FD_INFO_MIXER,
FD_INFO_STREAM,
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 29, 2011 at 04:39:39PM +0800, Arun Raghavan wrote: [...] > So you're in a mode that supports digital output (S/PDIF or HDMI) and > the appropriate formats are set on the sink? If yes, then the output of Which format should I set on the sink to make the passthrough work? > pactl list and gst-launch output with --gst-debug=pulse*:3 while playing > would help. Here's the output just now: (using -v only, I'll use debug level 3 to give more info). Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstDcaParse:dcaparse0.GstPad:sink: caps = audio/x-dts, rate=(int)44100, channels=(int)6, depth=(int)14, endianness=(int)1234, framed=(boolean)false /GstPipeline:pipeline0/GstDcaParse:dcaparse0.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0.GstGhostPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstTypeFindElement:typefind.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstGhostPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstGhostPad:sink.GstProxyPad:proxypad1: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDcaParse:dcaparse1.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDcaParse:dcaparse1.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDtsDec:dtsdec0.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstDecodePad:src0: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDtsDec:dtsdec0.GstPad:src: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstPulseSink:pulseaudiosink-sink.GstPad:sink: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstDecodePad:src0.GstProxyPad:proxypad5: caps = audio/x-raw-flo
Re: [pulseaudio-discuss] ask about passthrough support
Hi Arun, On Thu, Sep 29, 2011 at 04:02:48PM +0800, Arun Raghavan wrote: [...] > Take a look at http://pulseaudio.org/wiki/Passthrough -- it gives you > the basic steps to set things up. I'll try to write up something more > comprehensive soon. That's great. FYI. I've installed the git version of gstreamer. > > The DTS-in-wav case is a bit dicey. In most cases, you should be able to > get the data out of wavparse, pass it to dcaparse and pass that on to > pulsesink or pulseaudio directly. I'm using this command: gst-launch filesrc location=test.wav ! wavparse ! dcaparse ! pulseaudiosink But this will utilize the dtsdec plugin, and the data is not passthroughed... > > However, it is possible that the file is made such that it is already > padded to the correct size for IEC958 transmission, which is a case we > do not currently handle. The reason being that pulsesink calls a gst > utility library to perform IEC 61937 payloading, which isn't possible in > these sort of files (no space left for the header). We should probably > just pass this on if the frames are the right size, but at the time, I > deferred this decision to later since I wasn't sure what to do. > > Regards, > Arun > -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 08, 2011 at 02:09:33AM +0800, Arun Raghavan wrote: [...] > > 3. To be able to use passthrough, do we still need changes on Gstreamer? > > Therefore people can simply use something like 'gst-launch xxx'. And > > how's that status? > > The base stuff is in git master, and some of it is en route > (https://bugzilla.gnome.org/show_bug.cgi?id=657179). Hi Arun, I've seen that the corresponding patch is already committed in gst-plugins-good repository. Reading the comments from the file: "It transparently takes care of passing compressed format as-is if the sink supports it, decoding if necessary, and changes to supported formats at runtime." I'm confused how it negotiates with underlying alsa device? Does it need some changes in alsa driver? E.g. I have an HDMI device, and I would like to pass a dts-wav file directly down to this device. Are there some commands like 'gst-launch filesrc location=test.wav ! pulseaudiosink'? -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing questions of module-switch-on-connect, module-device-manager and device profiles
On Wed, Sep 28, 2011 at 01:14:32PM +0800, David Henningsson wrote: [...] > > Hi David, > > > > Thanks for the patches, a little more request from you... Is there any > > better way to download them all instead of downloading them one by one? > > (I'm not very familar with launchpad system...) > > If you have bzr installed, you run "bzr branch > lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric" Thanks a lot! -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing questions of module-switch-on-connect, module-device-manager and device profiles
On Wed, Sep 28, 2011 at 12:53:32PM +0800, David Henningsson wrote: > On 09/28/2011 03:45 AM, Lu Guanqun wrote: > > On Wed, Sep 21, 2011 at 02:16:23PM +0800, David Henningsson wrote: > > [...] > >> In a later version of these patches I have removed this functionality > >> from m-s-on-c and put it into a separate module. I haven't posted that > >> here yet as I didn't think it would be much reason to do so before 1.0 > >> is released. > > > > Hi David, > > > > Do you have a separate git tree which tracks your latest developement on > > this jack detection stuff? If there's one, that'll be great. > > > > Right now the latest version of patches is here: > http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric/files/head:/debian/patches/ > > (see patches 0601 - 0616) Hi David, Thanks for the patches, a little more request from you... Is there any better way to download them all instead of downloading them one by one? (I'm not very familar with launchpad system...) > > Colin, will you let me know when you feel it's time to supply them for > upstream inclusion? > > -- > David Henningsson, Canonical Ltd. > http://launchpad.net/~diwic -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 1.0
On Tue, Sep 27, 2011 at 09:20:44PM +0800, Arun Raghavan wrote: > On Tue, 2011-09-27 at 10:37 +0100, Colin Guthrie wrote: > > Hi! > > > > Yup, that's right it's 1.0 time at last. > > > > So this has been a long time coming, but finally it's out there! > > > > I've covered a lot of things already in the previous release notes and > > we have a fairly extensive summary of things over on the release notes > > page here: http://pulseaudio.org/wiki/Notes/1.0 > > The Trac instance on pulseaudio.org is crying in a corner again. While > it recovers, the same notes are available at > http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0 Wow! A nicely written releasenote, thanks Arun. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing questions of module-switch-on-connect, module-device-manager and device profiles
On Wed, Sep 21, 2011 at 02:16:23PM +0800, David Henningsson wrote: [...] > In a later version of these patches I have removed this functionality > from m-s-on-c and put it into a separate module. I haven't posted that > here yet as I didn't think it would be much reason to do so before 1.0 > is released. Hi David, Do you have a separate git tree which tracks your latest developement on this jack detection stuff? If there's one, that'll be great. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Muting while changing ports
On Thu, Sep 22, 2011 at 08:55:04AM +0800, Lu Guanqun wrote: > On Wed, Sep 21, 2011 at 10:16:52PM +0800, Tanu Kaskinen wrote: > > On Wed, 2011-09-21 at 17:08 +0300, David Henningsson wrote: > > > On 09/21/2011 02:22 PM, Tanu Kaskinen wrote: > > > > Hi, > > > > > > > > There exists audio hardware that produces annoying noise (snap, crackle, > > > > pop) when changing the alsa mixer settings, unless hw mute is used > > > > during the mixer changes. I'm planning to fix this by using hw mute > > > > during path activation, if the path provides hw mute. If anyone has > > > > objections or other comments, the best time to publish them would be > > > > now :) > > > > > > Does not sound like anything I would like to enable by default - e g, > > > what if hw mute introduces a click, and changing the volume does not? > > > > If you think that such hardware is likely to exist, then I guess I'll > > have to make this configurable, and disable it by default. The path > > configuration files would get a new option for the [General] section: > > "mute-during-activation = yes/no". Does that sound ok to you? > > I have the same concern with David, but as it's configurable, I'm OK > with it. Hi Tanu, Sorry to send it again, but as a second thought, isn't the annoying noise a bug of underlying driver? I once met with a poorly written driver that causes lots of unpleasant noises (though not in mixer changing operation). -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Muting while changing ports
On Wed, Sep 21, 2011 at 10:16:52PM +0800, Tanu Kaskinen wrote: > On Wed, 2011-09-21 at 17:08 +0300, David Henningsson wrote: > > On 09/21/2011 02:22 PM, Tanu Kaskinen wrote: > > > Hi, > > > > > > There exists audio hardware that produces annoying noise (snap, crackle, > > > pop) when changing the alsa mixer settings, unless hw mute is used > > > during the mixer changes. I'm planning to fix this by using hw mute > > > during path activation, if the path provides hw mute. If anyone has > > > objections or other comments, the best time to publish them would be > > > now :) > > > > Does not sound like anything I would like to enable by default - e g, > > what if hw mute introduces a click, and changing the volume does not? > > If you think that such hardware is likely to exist, then I guess I'll > have to make this configurable, and disable it by default. The path > configuration files would get a new option for the [General] section: > "mute-during-activation = yes/no". Does that sound ok to you? I have the same concern with David, but as it's configurable, I'm OK with it. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reply-to
On Wed, Sep 21, 2011 at 04:41:24PM +0800, Maarten Bosmans wrote: > Huh? I clicked on reply-all (in gmail) on Guanqun's message and it put > Colin in the CC. How is that possible? > > 2011/9/21 Lu Guanqun : > >> So "tricking" people into following the list has IMO many benefits which > >> go beyond simple convenience for the end recipient. > > > > I like your idea of "tricking" people to read the mailing list. :) I'll > > make my polling more frequently. > > It sound like you're not subscribed, but reading the list archives > regularly. How about just subscribing to the list? If you don't want > to use your work mail address, use a webmail service. Hi Maarten, I've subscribed, but I've filtered this mailing list to one specific folder, if I'm not CC-ed, the mail will not be in my main inbox, thus I have to poll this folder to read what's up in the mailing list. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reply-to
On Wed, Sep 21, 2011 at 03:57:29PM +0800, Colin Guthrie wrote: [...] > That and we're also a community. We want people who have received help > and advice from us in the past to help pass information and tips on to > others. Myself and a few of the other core folks try very hard to reply > to people seeking help on the list and I think it's important to > encourage everyone who follows it to do the same and spread the burden. You and other guys are doing a pretty good job to make it happen. Appreciated. > > > So "tricking" people into following the list has IMO many benefits which > go beyond simple convenience for the end recipient. I like your idea of "tricking" people to read the mailing list. :) I'll make my polling more frequently. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reply-to (was: How does pulseaudio find the new default sink/source when current one is unlinked?)
On Wed, Sep 21, 2011 at 02:09:01PM +0800, David Henningsson wrote: > On 09/21/2011 05:21 AM, Lu Guanqun wrote: > > On Tue, Sep 20, 2011 at 08:32:39PM +0800, Colin Guthrie wrote: > > [...] > >> See the blog post I pointed to my reply on the other thread. > > > > Hi Col, > > > > This might not be related to this thread, but can I request you to > > change the behaviour of this mailing list a bit? Generally what this > > mailing list does is to reply to the list directly without the replier > > been CC-ed. However, in this way, if they don't check this mailing list > > regularly, they might miss some mails. Is it possible to change it to > > default Cc the person? > > Being in the same situation for another list: AFAIK, this is not > possible to set globally. You can choose to have the mailinglist or the > original sender as being the default to reply to, whereas having the > original sender will lead to people mistakenly responding in private. > This is IMO worse than people mistakenly not cc:ing in the original poster. > > I think it is up to everyone to be disciplined enough to use "Reply All" > instead of "Reply" in their e-mail reader. Yes, it's better for everyone to use "Reply to All", but there's some extra effort. What makes think the behaviour might be changed is when I check the email header, there's a line below: Reply-To: General PulseAudio Discussion Thus, the mail client will try to reply to this address first. I'm asking is it possible to remove this line. [I'm not familiar with email processing system, so that might be wrong...] -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How does pulseaudio find the new default sink/source when current one is unlinked?
On Tue, Sep 20, 2011 at 08:32:39PM +0800, Colin Guthrie wrote: [...] > See the blog post I pointed to my reply on the other thread. Hi Col, This might not be related to this thread, but can I request you to change the behaviour of this mailing list a bit? Generally what this mailing list does is to reply to the list directly without the replier been CC-ed. However, in this way, if they don't check this mailing list regularly, they might miss some mails. Is it possible to change it to default Cc the person? -- guanqun ___ 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 Tue, Sep 20, 2011 at 04:25:10PM +0800, David Henningsson wrote: [...] > Hi Lu, > > This is interesting. If there was something in the kernel that makes > Atom HDA controllers (?) report the wrong timing info, and this was > later fixed, could you point me to that patch? Hi David, We're using Moorestown as our platform, http://en.wikipedia.org/wiki/Moorestown_(computing_platform) It don't use HDA controller, instead, it uses a kind of PMIC as its audio codec. And the patch was deep in the firmware, so it doesn't help your bug very much I'm afraid... Sorry about that... -- guanqun ___ 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, Sep 19, 2011 at 11:49:03PM +0800, David Henningsson wrote: > 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? Hi David, Thanks for the patch, rate limiting the rewinding seems a good idea, however, I don't have Atom machine right on my hand. I met the flood of rewinds before, but that was later root caused to the wrong report of timing info from underlying device. After this was fixed, no flood of rewinds were seen. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Does pulseaudo provide API to set the active port of a sink/source?
On Tue, Sep 20, 2011 at 03:07:49PM +0800, Lin, Mengdong wrote: > I want to switch to the loud speaker/mike (hand-free) during a phone call > without unplugging my wired headset. And the wired-headset and speaker/mike > are two ports of the ALSA sink/source on my platform. > > Does PA provide an API that can to set the active port on a sink/source? > I only found the API to set sink/source "pa_context_set_default_sink" but no > API to set the port. Check PROTOCOL file gives me back: ~ ### v16, implemented by >= 0.9.15 new messages: PA_COMMAND_SET_SINK_PORT PA_COMMAND_SET_SOURCE_PORT ~ And the corresponding pa_context_set_sink_port_by_index is possibly what you want. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 15, 2011 at 01:58:41PM +0800, Arun Raghavan wrote: > On Thu, 2011-09-15 at 11:22 +0800, Lu Guanqun wrote: > > On Thu, Sep 08, 2011 at 02:19:41AM +0800, Arun Raghavan wrote: > > > On Wed, 2011-09-07 at 11:09 -0700, Arun Raghavan wrote: > > > > On Wed, 2011-09-07 at 14:20 +0800, Lu Guanqun wrote: > > > > > Hi Arun, > > > > > > > > > > I have several things unclear about passthrough support: > > > > > > > > I'm talking about this work at Linux Plumbers' Conference on Friday. If > > > > videos are available, I'll link to them -- hopefully that should make > > > > the motivation clear. > > > > > > Oh, phew, no video -- I'm still happy to answer any questions you > > > have. :) > > > > Hi Arun, > > > > I've a dumb question... On my laptop, when I use pacat --passthrough > > , does it mean the passthrough mode is used? Though it's > > not the usual case as hardware decoding is not used. > > Yes -- all the logic that works with passthrough streams goes via > pa_sink_input_is_passthrough(), which you will see checks if the stream > has non-PCM data OR has the PASSTHROUGH flag set (which is what > --passthrough does). That's cool, thanks for the info. If this ALSA device can hard decode, then in this scenario, it can play, let's say, MP3 file on the fly. :) -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 08, 2011 at 02:19:41AM +0800, Arun Raghavan wrote: > On Wed, 2011-09-07 at 11:09 -0700, Arun Raghavan wrote: > > On Wed, 2011-09-07 at 14:20 +0800, Lu Guanqun wrote: > > > Hi Arun, > > > > > > I have several things unclear about passthrough support: > > > > I'm talking about this work at Linux Plumbers' Conference on Friday. If > > videos are available, I'll link to them -- hopefully that should make > > the motivation clear. > > Oh, phew, no video -- I'm still happy to answer any questions you > have. :) Hi Arun, I've a dumb question... On my laptop, when I use pacat --passthrough , does it mean the passthrough mode is used? Though it's not the usual case as hardware decoding is not used. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 08, 2011 at 02:19:41AM +0800, Arun Raghavan wrote: > On Wed, 2011-09-07 at 11:09 -0700, Arun Raghavan wrote: > > On Wed, 2011-09-07 at 14:20 +0800, Lu Guanqun wrote: > > > Hi Arun, > > > > > > I have several things unclear about passthrough support: > > > > I'm talking about this work at Linux Plumbers' Conference on Friday. If > > videos are available, I'll link to them -- hopefully that should make > > the motivation clear. > > Oh, phew, no video -- I'm still happy to answer any questions you > have. :) Thanks Arun for your info. At least there'll be slides published? -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] ask about passthrough support
Hi Arun, I have several things unclear about passthrough support: 1. Is it only useful when there's hardware decoding functionality available? Can I simply test out passthrough with the current ALSA sound card (some emulations possible)? 2. As right now, ALSA only have PCM interface, how do we pass the encoded data down? Do we have to use some other driver specific interfaces? Vinod, recently posted some patches to add compression interface for ALSA. Is that needed? 3. To be able to use passthrough, do we still need changes on Gstreamer? Therefore people can simply use something like 'gst-launch xxx'. And how's that status? -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log
On Thu, Sep 01, 2011 at 09:53:34AM +0800, David Henningsson wrote:
> > Hi Col,
> >
> > Do you think it's better to invoke pa_thread_new("alsa-sink 0", func, u)
> > or adding another index after the plain name? (e.g.
> > pa_thread_new("alsa-sink", index, func, u))
> >
>
> Having seen this in action for a while I'd say I like the idea in
> general, but I have a few things to wish for if possible:
Hi David,
Thanks for your suggestions.
>
> 1) Yes, having "alsa-sink 0" (for whatever 0 means, sink index, module
> index) is helpful, e g when you have four soundcards and get an
> "Underrun from ALSA!" message and don't know what card that is. My
> favorite would be if you can get the ALSA shortname in (e g "alsa-sink
> SB" or "alsa-sink Headset") but I don't know if that's easy enough to do.
>
> 2) If we can eliminate this information from the main thread (empty
> brackets or just remove it altogether), that would reduce most of the
> log size increased by this patch.
On point 2, do you mean "[pulseaudio] " should be better changed to
"[] " or "" instead? I agree it's annoying to see lots of
"pulseaudio" messages on the log.
I can help to make our debugging life easier. :)
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] module-switch-on-connect: Don't switch to a monitoring source
Hi David,
On Wed, Aug 24, 2011 at 08:01:00PM +0800, David Henningsson wrote:
> Buglink: http://bugs.launchpad.net/bugs/831675
Opening the above link gives me back nothing...
~
Lost something?
There’s no page with this address in Launchpad.
Check that you entered the address correctly, or search for it:
~
> Signed-off-by: David Henningsson
> ---
> src/modules/module-switch-on-connect.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/src/modules/module-switch-on-connect.c
> b/src/modules/module-switch-on-connect.c
> index b121fd9..b1570b1 100644
> --- a/src/modules/module-switch-on-connect.c
> +++ b/src/modules/module-switch-on-connect.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -113,6 +114,10 @@ static pa_hook_result_t source_put_hook_callback(pa_core
> *c, pa_source *source,
> if (c->state != PA_CORE_RUNNING)
> return PA_HOOK_OK;
>
> +/* Don't switch to a monitoring source */
> +if (source->monitor_of)
> +return PA_HOOK_OK;
> +
> /* Don't switch to any internal devices */
> if ((s = pa_proplist_gets(source->proplist, PA_PROP_DEVICE_BUS))) {
> if (pa_streq(s, "pci"))
> --
> 1.7.5.4
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events
On Tue, Aug 23, 2011 at 05:00:58PM +0800, Colin Guthrie wrote:
> Yes, the latest code is better but what I was meaning was something like:
>
> diff --git a/src/utils/pacat.c b/src/utils/pacat.c
> index f687402..2568db5 100644
> --- a/src/utils/pacat.c
> +++ b/src/utils/pacat.c
> @@ -91,6 +91,8 @@ static int32_t latency_msec = 0, process_time_msec = 0;
> static pa_bool_t raw = TRUE;
> static int file_format = -1;
>
> +static int cork_requests = 0;
> +
> /* A shortcut for terminating the application */
> static void quit(int ret) {
> pa_assert(mainloop_api);
> @@ -408,6 +410,15 @@ static void stream_event_callback(pa_stream *s,
> const char *name, pa_proplist *p
>
> t = pa_proplist_to_string_sep(pl, ", ");
> pa_log("Got event '%s', properties '%s'", name, t);
> +
> +if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK)) {
> +if (!cork_requests)
> +pa_operation_unref(pa_stream_cork(s, 1, NULL, NULL));
> +cork_requests++;
> +} else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK)) {
> +cork_requests--;
> +if (!cork_requests)
> + pa_operation_unref(pa_stream_cork(s, 0, NULL, NULL));
> +}
> +
> pa_xfree(t);
> }
>
>
>
> (not a real patch!)
>
>
> This way the actual operation is only sent at the transition of 0->1 and
> not 1->2 etc. (and the opposite, it will only be sent when doing 1->0
> and not from 2->1).
>
> I think this makes sense, but other opinions are welcomed too.
I see your point of only doing the corking at 0->1 and vice versa.
>
> >> We may at some point have to change the semantics at the server side to
> >> deal with the start_corked issue, and thus this is likely more robust in
> >> those circumstances.
BTW: Which semantics are we trying to change to? I may not have the
context here...
> >
> > It should. However for 'pacat', it doesn't set START_CORKED flag, so I'm
> > afraid there's no such problem for 'pacat'.
>
> Aye, but gstreamer does... so the problem is real and thus any "example"
> code should probably follow the best practice principles - now we only
> need to decide what "best practice" really is :p
>
> Col
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events
Hi Col,
On Tue, Aug 23, 2011 at 04:22:48PM +0800, Colin Guthrie wrote:
> 'Twas brillig, and Lu Guanqun at 23/08/11 07:18 did gyre and gimble:
> > Pacat remembers the number of cork requests, and then cork/uncork the stream
> > accordingly.
> >
> > With this change, it makes below test script work correctly:
> >
> > pacat -p --property=media.role="music" &
> > sleep 2
> > pacat -p --property=media.role="phone"
> > wait
>
>
>
> Interesting, this is likely good as a test bed/example.
Thanks. I was trying module-cork-music-on-phone and came up with this
little script. :)
>
> That said, I'm not sure we should be sending the operations every time.
>
> Perhaps we should only send a cork req when the count moves form 0->1
> and an uncork when the count moves from 1->0?
At my first attempt, I'm only doing something like below:
diff --git a/src/utils/pacat.c b/src/utils/pacat.c
index f687402..41817ff 100644
--- a/src/utils/pacat.c
+++ b/src/utils/pacat.c
@@ -408,6 +410,12 @@ static void stream_event_callback(pa_stream *s, const char
*name, pa_proplist *p
t = pa_proplist_to_string_sep(pl, ", ");
pa_log("Got event '%s', properties '%s'", name, t);
+
+if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK))
+pa_operation_unref(pa_stream_cork(s, 1, NULL, NULL));
+else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK))
+pa_operation_unref(pa_stream_cork(s, 0, NULL, NULL));
+
pa_xfree(t);
}
But I read the mailing list and once someone said it's better for client
to remember how many cork requests it receives and only uncork it when
it reaches zero. That's why I changed to the current style.
Do you think my original code is better for this case?
>
> We may at some point have to change the semantics at the server side to
> deal with the start_corked issue, and thus this is likely more robust in
> those circumstances.
It should. However for 'pacat', it doesn't set START_CORKED flag, so I'm
afraid there's no such problem for 'pacat'.
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events
Pacat remembers the number of cork requests, and then cork/uncork the stream
accordingly.
With this change, it makes below test script work correctly:
pacat -p --property=media.role="music" &
sleep 2
pacat -p --property=media.role="phone"
wait
Signed-off-by: Lu Guanqun
---
src/utils/pacat.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/utils/pacat.c b/src/utils/pacat.c
index f687402..2568db5 100644
--- a/src/utils/pacat.c
+++ b/src/utils/pacat.c
@@ -91,6 +91,8 @@ static int32_t latency_msec = 0, process_time_msec = 0;
static pa_bool_t raw = TRUE;
static int file_format = -1;
+static int cork_requests = 0;
+
/* A shortcut for terminating the application */
static void quit(int ret) {
pa_assert(mainloop_api);
@@ -408,6 +410,15 @@ static void stream_event_callback(pa_stream *s, const char
*name, pa_proplist *p
t = pa_proplist_to_string_sep(pl, ", ");
pa_log("Got event '%s', properties '%s'", name, t);
+
+if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK)) {
+cork_requests++;
+pa_operation_unref(pa_stream_cork(s, !!cork_requests, NULL, NULL));
+} else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK)) {
+cork_requests--;
+pa_operation_unref(pa_stream_cork(s, !!cork_requests, NULL, NULL));
+}
+
pa_xfree(t);
}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How's the integration of UCM into pulseaudio?
I searched the list and found Jorge Eduardo Candelaria is doing the work. Loop in for more info... On Fri, Aug 19, 2011 at 02:06:32PM +0800, Lu Guanqun wrote: > Hi list, > > I'm curious what's the status of integration of UCM? Are there any > plans, roadmap or patches are ready and they haven't got into git > master? > > Any comments are welcomed. > > Thanks! > -- > guanqun > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] How's the integration of UCM into pulseaudio?
Hi list, I'm curious what's the status of integration of UCM? Are there any plans, roadmap or patches are ready and they haven't got into git master? Any comments are welcomed. Thanks! -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] memblock: fix memory leak when pa_shm_create_rw fails
On Mon, Aug 15, 2011 at 03:36:51PM +0800, Maarten Bosmans wrote:
> Good catch!
>
> An alternative solution (and IMHO better one) would be to move the two
> lines allocating the mutex and semaphore below the if-block that can
> return. That way you avoid the memory-leak situation alltogether.
Thanks for the suggestion, I decided to move it a bit lower because
lines around the if statement are all about blocks related. ;)
Please see the attachment.
--
guanqun
>From 3e991718386e8aae5e8d333d012a522abc85f0f3 Mon Sep 17 00:00:00 2001
From: Lu Guanqun
Date: Mon, 15 Aug 2011 09:51:37 +0800
Subject: [PATCH] memblock: fix memory leak when pa_shm_create_rw fails
Signed-off-by: Lu Guanqun
---
src/pulsecore/memblock.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c
index e34a739..19be151 100644
--- a/src/pulsecore/memblock.c
+++ b/src/pulsecore/memblock.c
@@ -711,9 +711,6 @@ pa_mempool* pa_mempool_new(pa_bool_t shared, size_t size) {
p = pa_xnew(pa_mempool, 1);
-p->mutex = pa_mutex_new(TRUE, TRUE);
-p->semaphore = pa_semaphore_new(0);
-
p->block_size = PA_PAGE_ALIGN(PA_MEMPOOL_SLOT_SIZE);
if (p->block_size < PA_PAGE_SIZE)
p->block_size = PA_PAGE_SIZE;
@@ -745,6 +742,9 @@ pa_mempool* pa_mempool_new(pa_bool_t shared, size_t size) {
PA_LLIST_HEAD_INIT(pa_memimport, p->imports);
PA_LLIST_HEAD_INIT(pa_memexport, p->exports);
+p->mutex = pa_mutex_new(TRUE, TRUE);
+p->semaphore = pa_semaphore_new(0);
+
p->free_slots = pa_flist_new(p->n_blocks);
return p;
--
1.7.6
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/2] memblock: use built-in function
Signed-off-by: Lu Guanqun
---
src/pulsecore/memblock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c
index 332fcb7..409c65e 100644
--- a/src/pulsecore/memblock.c
+++ b/src/pulsecore/memblock.c
@@ -229,7 +229,7 @@ static pa_memblock *memblock_new_appended(pa_mempool *p,
size_t length) {
/* If -1 is passed as length we choose the size for the caller. */
if (length == (size_t) -1)
-length = p->block_size - PA_ALIGN(sizeof(pa_memblock));
+length = pa_mempool_block_size_max(p);
b = pa_xmalloc(PA_ALIGN(sizeof(pa_memblock)) + length);
PA_REFCNT_INIT(b);
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/2] memblock: fix memory leak when pa_shm_create_rw fails
Signed-off-by: Lu Guanqun
---
src/pulsecore/memblock.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c
index e34a739..332fcb7 100644
--- a/src/pulsecore/memblock.c
+++ b/src/pulsecore/memblock.c
@@ -728,6 +728,8 @@ pa_mempool* pa_mempool_new(pa_bool_t shared, size_t size) {
}
if (pa_shm_create_rw(&p->memory, p->n_blocks * p->block_size, shared,
0700) < 0) {
+pa_semaphore_free(p->semaphore);
+pa_mutex_free(p->mutex);
pa_xfree(p);
return NULL;
}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Need help to reduce delay with USB, mic using pulseaudio
On Fri, Aug 12, 2011 at 12:07:18AM +0800, Colin Guthrie wrote: > 'Twas brillig, and Lu Guanqun at 11/08/11 17:20 did gyre and gimble: > > Hi Ashwani, > > > > On Thu, Aug 11, 2011 at 11:02:41PM +0800, Pierre-Louis Bossart wrote: > >>> I am attaching the pulseaudio usb mic delay log. > >>> When I am running gst-launch-0.10 ! pulsesrc ! pulsesink on pandaboard > >>> getting around 2-3 sec. on the fly audio delay. > >>> > >>> Please suggest how to resolve this problem. > >> > >> Use module-loopback and play with the latency parameters. > > > > In case you don't know what the latency parameters are, on the > > gst-launch line, you can append these parameters: e.g. > > > > gst-launch-0.10 pulsesrc buffer-time= latency-time= ! > > pulsesink buffer-time= latency-time= > > > > I suspect Pierre was referring to the latency_usec param on module-loopback. Waiting Pierre to clarify. ;) I once played with the buffer time and latency time on gstreamer, it could reduce the delay to some extent. -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/3] Move i18n.[ch] to src/pulsecore
e
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/pulse/volume.c b/src/pulse/volume.c
> > index 82e5757..cf0a226 100644
> > --- a/src/pulse/volume.c
> > +++ b/src/pulse/volume.c
> > @@ -27,9 +27,8 @@
> > #include
> > #include
> >
> > -#include
> > -
> > #include
> > +#include
> > #include
> > #include
> >
> > diff --git a/src/pulsecore/i18n.c b/src/pulsecore/i18n.c
> > new file mode 100644
> > index 000..7f25b20
> > --- /dev/null
> > +++ b/src/pulsecore/i18n.c
> > @@ -0,0 +1,38 @@
> > +/***
> > + This file is part of PulseAudio.
> > +
> > + Copyright 2008 Lennart Poettering
> > +
> > + 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
> > + Lesser 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
> > +#endif
> > +
> > +#include
> > +
> > +#include "i18n.h"
> > +
> > +void pa_init_i18n(void) {
> > +
> > +PA_ONCE_BEGIN {
> > +
> > +bindtextdomain(GETTEXT_PACKAGE, PULSE_LOCALEDIR);
> > +bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8");
> > +
> > +} PA_ONCE_END;
> > +}
> > diff --git a/src/pulsecore/i18n.h b/src/pulsecore/i18n.h
> > new file mode 100644
> > index 000..d828bec
> > --- /dev/null
> > +++ b/src/pulsecore/i18n.h
> > @@ -0,0 +1,61 @@
> > +#ifndef foopulsei18nhfoo
> > +#define foopulsei18nhfoo
> > +
> > +/***
> > + This file is part of PulseAudio.
> > +
> > + Copyright 2008 Lennart Poettering
> > +
> > + 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
> > + Lesser 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.
> > +***/
> > +
> > +#include
> > +
> > +PA_C_DECL_BEGIN
> > +
> > +#if !defined(GETTEXT_PACKAGE)
> > +#error "Something is very wrong here, config.h needs to be included first"
> > +#endif
> > +
> > +#ifdef ENABLE_NLS
> > +
> > +#include
> > +
> > +#define _(String) dgettext(GETTEXT_PACKAGE, String)
> > +#ifdef gettext_noop
> > +#define N_(String) gettext_noop(String)
> > +#else
> > +#define N_(String) (String)
> > +#endif
> > +
> > +#else /* NLS is disabled */
> > +
> > +#define _(String) (String)
> > +#define N_(String) (String)
> > +#define textdomain(String) (String)
> > +#define gettext(String) (String)
> > +#define dgettext(Domain,String) (String)
> > +#define dcgettext(Domain,String,Type) (String)
> > +#define bindtextdomain(Domain,Directory) (Domain)
> > +#define bind_textdomain_codeset(Domain,Codeset) (Codeset)
> > +
> > +#endif /* ENABLE_NLS */
> > +
> > +void pa_init_i18n(void);
> > +
> > +PA_C_DECL_END
> > +
> > +#endif
> > diff --git a/src/pulsecore/lock-autospawn.c b/src/pulsecore/lock-autospawn.c
> > index 40aa5e9..b1d414b 100644
> > --- a/src/pulsecore/lock-autospawn.c
> > +++ b/src/pulsecore/lock-autospawn.c
> > @@ -32,9 +32,9 @@
> > #endif
> >
> > #include
> > -#include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> > index 714b3d2..42a8eb3 100644
> > --- a/src/pulsecore/sink.c
> > +++ b/src/pulsecore/sink.c
> > @@ -34,10 +34,10 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/tests/resampler-test.c b/src/tests/resampler-test.c
> > index 78461da..545c0e0 100644
> > --- a/src/tests/resampler-test.c
> > +++ b/src/tests/resampler-test.c
> > @@ -25,13 +25,13 @@
> > #include
> > #include
> >
> > -#include
> > #include
> >
> > #include
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/utils/pacat.c b/src/utils/pacat.c
> > index 323f071..f687402 100644
> > --- a/src/utils/pacat.c
> > +++ b/src/utils/pacat.c
> > @@ -37,15 +37,14 @@
> >
> > #include
> >
> > -#include
> > #include
> > #include
> >
> > -#include
> > #include
> > +#include
> > #include
> > +#include
> > #include
> > -#include
> >
> > #define TIME_EVENT_USEC 5
> >
> > diff --git a/src/utils/pacmd.c b/src/utils/pacmd.c
> > index f077980..4166964 100644
> > --- a/src/utils/pacmd.c
> > +++ b/src/utils/pacmd.c
> > @@ -34,8 +34,8 @@
> >
> > #include
> > #include
> > -#include
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/utils/pactl.c b/src/utils/pactl.c
> > index e6f9c17..38c78a8 100644
> > --- a/src/utils/pactl.c
> > +++ b/src/utils/pactl.c
> > @@ -35,9 +35,9 @@
> >
> > #include
> >
> > -#include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/src/utils/pasuspender.c b/src/utils/pasuspender.c
> > index e1ee251..90881b2 100644
> > --- a/src/utils/pasuspender.c
> > +++ b/src/utils/pasuspender.c
> > @@ -40,8 +40,9 @@
> > #include
> > #endif
> >
> > -#include
> > #include
> > +
> > +#include
> > #include
> >
> > static pa_context *context = NULL;
> > diff --git a/src/utils/pax11publish.c b/src/utils/pax11publish.c
> > index 41361a1..ddfb724 100644
> > --- a/src/utils/pax11publish.c
> > +++ b/src/utils/pax11publish.c
> > @@ -31,10 +31,10 @@
> > #include
> >
> > #include
> > -#include
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > --
> > 1.7.4.1
> >
> >
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
guanqun
>From 108cb510f29ade66ec5478b0f9f9071dfb080101 Mon Sep 17 00:00:00 2001
From: Lu Guanqun
Date: Fri, 12 Aug 2011 00:07:26 +0800
Subject: [PATCH] i18n: po file fixes
Signed-off-by: Lu Guanqun
---
po/POTFILES.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index f893655..f4f6c22 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -142,6 +142,7 @@ src/pulsecore/sound-file-stream.c
src/pulsecore/memblockq.c
src/pulsecore/protocol-http.c
src/pulsecore/semaphore-win32.c
+src/pulsecore/i18n.c
src/daemon/cpulimit.c
src/daemon/ltdl-bind-now.c
src/daemon/main.c
@@ -157,7 +158,6 @@ src/pulse/proplist.c
src/pulse/xmalloc.c
src/pulse/ext-stream-restore.c
src/pulse/stream.c
-src/pulse/i18n.c
src/pulse/util.c
src/pulse/utf8.c
src/pulse/mainloop-api.c
--
1.7.6
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Need help to reduce delay with USB, mic using pulseaudio
Hi Ashwani, On Thu, Aug 11, 2011 at 11:02:41PM +0800, Pierre-Louis Bossart wrote: > > I am attaching the pulseaudio usb mic delay log. > > When I am running gst-launch-0.10 ! pulsesrc ! pulsesink on pandaboard > > getting around 2-3 sec. on the fly audio delay. > > > > Please suggest how to resolve this problem. > > Use module-loopback and play with the latency parameters. In case you don't know what the latency parameters are, on the gst-launch line, you can append these parameters: e.g. gst-launch-0.10 pulsesrc buffer-time= latency-time= ! pulsesink buffer-time= latency-time= -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2] thread-posix: remove duplicate code for setting thread name
On Thu, Aug 11, 2011 at 04:30:12PM +0800, Colin Guthrie wrote:
> 'Twas brillig, and Lu Guanqun at 11/08/11 02:59 did gyre and gimble:
> > According to the principle of DRY (don't repeat yourself), remove the code
> > for
> > setting thread name in thread-posix.c.
> >
> > Signed-off-by: Lu Guanqun
> > ---
> > src/pulsecore/thread-posix.c | 20 ++--
> > 1 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
> > index 3f4ae5c..9a8c51b 100644
> > --- a/src/pulsecore/thread-posix.c
> > +++ b/src/pulsecore/thread-posix.c
> > @@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
> >
> > PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
> >
> > +static void set_thread_name(const char *name) {
> > +#ifdef __linux__
> > +prctl(PR_SET_NAME, name);
> > +#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
> > +pthread_setname_np(name);
> > +#endif
> > +}
> > +
> > static void* internal_thread_func(void *userdata) {
> > pa_thread *t = userdata;
> > pa_assert(t);
> >
> > -#ifdef __linux__
> > -prctl(PR_SET_NAME, t->name);
> > -#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
> > -pthread_setname_np(t->name);
> > -#endif
> > +set_thread_name(t->name);
> >
> > t->id = pthread_self();
> >
> > @@ -175,11 +179,7 @@ void pa_thread_set_name(pa_thread *t, const char
> > *name) {
> > pa_xfree(t->name);
> > t->name = pa_xstrdup(name);
> >
> > -#ifdef __linux__
> > -prctl(PR_SET_NAME, name);
> > -#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
> > -pthread_setname_np(name);
> > -#endif
> > +set_thread_name(name);
> > }
> >
> > const char *pa_thread_get_name(pa_thread *t) {
>
>
> Am I blind or is pa_thread_set_name() itself redundant? I cannot find
> any calls to it
Good catch! I overlooked the code, I thought it was called in
pa_thread_new(). Do we need to add it in pa_thread_new() btw?
>
> If it's not used, we should just remove it and thus make the duplicated
> code no longer duplicated
>
> 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
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH v2] thread-posix: remove duplicate code for setting thread name
According to the principle of DRY (don't repeat yourself), remove the code for
setting thread name in thread-posix.c.
Signed-off-by: Lu Guanqun
---
src/pulsecore/thread-posix.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
index 3f4ae5c..9a8c51b 100644
--- a/src/pulsecore/thread-posix.c
+++ b/src/pulsecore/thread-posix.c
@@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
+static void set_thread_name(const char *name) {
+#ifdef __linux__
+prctl(PR_SET_NAME, name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
+pthread_setname_np(name);
+#endif
+}
+
static void* internal_thread_func(void *userdata) {
pa_thread *t = userdata;
pa_assert(t);
-#ifdef __linux__
-prctl(PR_SET_NAME, t->name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
-pthread_setname_np(t->name);
-#endif
+set_thread_name(t->name);
t->id = pthread_self();
@@ -175,11 +179,7 @@ void pa_thread_set_name(pa_thread *t, const char *name) {
pa_xfree(t->name);
t->name = pa_xstrdup(name);
-#ifdef __linux__
-prctl(PR_SET_NAME, name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
-pthread_setname_np(name);
-#endif
+set_thread_name(name);
}
const char *pa_thread_get_name(pa_thread *t) {
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] thread-posix: remove duplicate code for setting thread name
On Wed, Aug 10, 2011 at 11:42:03PM +0800, Maarten Bosmans wrote:
> 2011/8/10 Lu Guanqun :
> > According to the principle of DRY (don't repeat yourself), remove the code
> > for
> > setting thread name in thread-posix.c.
> >
> > Signed-off-by: Lu Guanqun
> > ---
> > src/pulsecore/thread-posix.c | 20 ++--
> > 1 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
> > index 3f4ae5c..81ae98d 100644
> > --- a/src/pulsecore/thread-posix.c
> > +++ b/src/pulsecore/thread-posix.c
> > @@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
> >
> > PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
> >
> > +static void pa_thread_set_name_raw(const char *name) {
>
> We generally do not prefix internal functions with pa_.\
> See http://pulseaudio.org/wiki/CodingStyle, #7.
Thanks for pointing this out. Will resend it.
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/2] sample-util: use built-in function
use built-in function pa_frame_aligned(). Signed-off-by: Lu Guanqun --- src/pulsecore/sample-util.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/pulsecore/sample-util.c b/src/pulsecore/sample-util.c index 8a13495..16ec4ad 100644 --- a/src/pulsecore/sample-util.c +++ b/src/pulsecore/sample-util.c @@ -734,7 +734,7 @@ void pa_volume_memchunk( pa_assert(c); pa_assert(spec); -pa_assert(c->length % pa_frame_size(spec) == 0); +pa_assert(pa_frame_aligned(c->length, spec)); pa_assert(volume); if (pa_memblock_is_silence(c->memblock)) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/2] thread-posix: remove duplicate code for setting thread name
According to the principle of DRY (don't repeat yourself), remove the code for
setting thread name in thread-posix.c.
Signed-off-by: Lu Guanqun
---
src/pulsecore/thread-posix.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
index 3f4ae5c..81ae98d 100644
--- a/src/pulsecore/thread-posix.c
+++ b/src/pulsecore/thread-posix.c
@@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
+static void pa_thread_set_name_raw(const char *name) {
+#ifdef __linux__
+prctl(PR_SET_NAME, name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
+pthread_setname_np(name);
+#endif
+}
+
static void* internal_thread_func(void *userdata) {
pa_thread *t = userdata;
pa_assert(t);
-#ifdef __linux__
-prctl(PR_SET_NAME, t->name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
-pthread_setname_np(t->name);
-#endif
+pa_thread_set_name_raw(t->name);
t->id = pthread_self();
@@ -175,11 +179,7 @@ void pa_thread_set_name(pa_thread *t, const char *name) {
pa_xfree(t->name);
t->name = pa_xstrdup(name);
-#ifdef __linux__
-prctl(PR_SET_NAME, name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP) && defined(OS_IS_DARWIN)
-pthread_setname_np(name);
-#endif
+pa_thread_set_name_raw(name);
}
const char *pa_thread_get_name(pa_thread *t) {
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] long delay after "paplay -s somehost foo.wav"
Hi, On Wed, Aug 10, 2011 at 09:47:47PM +0800, Paul Fox wrote: > colin wrote: > > 'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble: > ... > > > but this: > > > paplay -s server one.wav > > > paplay -s server two.wav > > > will result in a delay of over 2 seconds between "one" and "two". > ... > > > > This is likely related to the drain. In order to be 100% sure that the > > data is no longer needed (as it may be needed by rewind buffers) we have > > to wait. > > > > There are a few bug reports about this kind of thing in e.g. the simple > > protocol, but I'm not sure we can solve it 100% in all cases. > > thanks. i found this: http://www.pulseaudio.org/ticket/866 > > it certainly sounds like a fix will be a long time coming. it feels > to me that there should be a way for a stream to be started with a > different "contract", i.e., "i will never rewind this stream. please > deliver the data on a best-effort basis. i don't require > acknowledgement of the last byte." i.e., exactly the conditions needed > by most real-world uses of pa_play. > > > The 2s delay is likely related to the amount of audio that is buffered > > by default. > > i've modified the pacat-simple.c example to let me play with the > pa_buffer_attr passed to pa_simple_new, but can't seem to find a > combination that avoids the 2s wait. I did some experiment to set the tsched buffer size down a little bit and for me the wait time becomes smaller. This makes sense since the total buffer becomes smaller and the time to wait it to be drained is smaller. As this parameter is not exported via module-udev-detect, so you have to use this hack method instead: pacmd >> list-modules [find the module index of your alsa card] >> unload-module >> load-module module-alsa-card device_id="0" name="pci-_00_1b.0" card_name="alsa_card.pci-_00_1b.0" namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties="module-udev-detect.discovered=1" tsched_buffer_size= [note the parameter here may differ from yours, but you can get it from list-modules above, see the arguments part] Change the tsched_buffer_size to some number smaller. How to decide the number? Before you unload this module, invoke list-sinks and check this property: device.buffering.buffer_size. You may need to try half the number again and again to see how it fixes your problem. The cons of this action is you gets poor power consumption, the wakeup gets more and if it's too small, more chances of underrun. Be cautious. It's more like a tuning thing. You can take a try. > > removing the call to pa_simple_drain(), however, and (hack alert!) > substituting usleep(10) seems to do the trick, for me. i do get > a click between played files, though, so i'm not done. > > paul > > > > > Col > > > > -- > > > > Colin Guthrie > > gmane(at)colin.guthr.ie > > http://colin.guthr.ie/ > > =- > paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.4 degrees) > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 4/4] Profiles can have sink and source ports, and announce that through the API.
On Mon, Aug 08, 2011 at 05:31:39PM +0800, David Henningsson wrote:
> On 2011-07-07 13:23, David Henningsson wrote:
> > diff --git a/src/pulse/introspect.h b/src/pulse/introspect.h
> > index 8e4cc97..259c57b 100644
> > --- a/src/pulse/introspect.h
> > +++ b/src/pulse/introspect.h
> > @@ -452,6 +452,10 @@ typedef struct pa_card_profile_info {
> > uint32_t n_sinks; /**< Number of sinks this
> > profile would create */
> > uint32_t n_sources; /**< Number of sources this
> > profile would create */
> > uint32_t priority; /**< The higher this value is
> > the more useful this profile is as a default */
> > +uint32_t n_sink_ports; /**< Number of entries in
> > sink_ports array \since MERGE_OF_JACK_DETECTION */
> > +pa_sink_port_info** sink_ports; /**< Array of available output
> > ports, or NULL. Array is terminated by an entry set to NULL. The number of
> > entries is stored in n_sink_ports. \since MERGE_OF_JACK_DETECTION */
> > +uint32_t n_source_ports;/**< Number of entries in
> > source_ports array \since MERGE_OF_JACK_DETECTION */
> > +pa_source_port_info** source_ports; /**< Array of available input
> > ports, or NULL. Array is terminated by an entry set to NULL. The number of
> > entries is stored in n_source_ports. \since MERGE_OF_JACK_DETECTION */
> > } pa_card_profile_info;
>
> I think I figured out why the addition above breaks the ABI: It's
What's the symptom of your breaking?
I'm not sure whether they fall into the same category but I'd like to
point this out. I met with some weird issues when I add some new fields
in `struct userdata` in alsa-sink.c, the problem is the module segfaults
when it runs to pa_alsa_refcnt_inc().
>From gdb output message, it seems the module loading mechanism forgot to
add some kind of base address to it. so it directly jumps to a smaller
address, which causes the seg fault.
(gdb) info reg
eax0x8060e08134614536
ecx0x1 1
edx0x0 0
ebx0xb3ab2d1c -1280627428
esp0xbfffe960 0xbfffe960
ebp0xbfffe9f8 0xbfffe9f8
esi0x808d318134796056
edi0xb3ab6dd2 -1280610862
eip0xb3ab04dc 0xb3ab04dc
eflags 0x282[ SF IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x15ba in ?? ()
(gdb) info reg
eax0x8060e08134614536
ecx0x1 1
edx0x0 0
ebx0xb3ab2d1c -1280627428
esp0xbfffe95c 0xbfffe95c
ebp0xbfffe9f8 0xbfffe9f8
esi0x808d318134796056
edi0xb3ab6dd2 -1280610862
eip0x15ba 0x15ba <--
eflags 0x10282 [ SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
the correct address for refcnt_inc should be:
(gdb) p pa_alsa_refcnt_inc
$1 = {void (void)} 0xb3a73460
> because pa_card_info has a pointer to an array of these objects, with
> the following comment:
>
> pa_card_profile_info* profiles; /**< Array of available profile, or
> NULL. Array is terminated by an entry with name set to NULL. Number of
> entries is stored in n_profiles */
>
> Which means the client has to rely on sizeof(pa_card_profile_info) to
> know the address of the second (and third, and so on) array entry. As
> sizeof(pa_card_profile_info) is changed, recompilation of clients is
> necessary.
>
> :-(
>
> Any good ideas as of how to avoid it?
>
> --
> David Henningsson
> http://launchpad.net/~diwic
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log
On Mon, Aug 08, 2011 at 03:38:48PM +0800, Colin Guthrie wrote:
> 'Twas brillig, and Lu Guanqun at 08/08/11 08:55 did gyre and gimble:
> > On Sat, Aug 06, 2011 at 07:10:16PM +0800, Colin Guthrie wrote:
> >> 'Twas brillig, and Pierre-Louis Bossart at 05/08/11 16:24 did gyre and
> >> gimble:
> >>>> there're multiple pthreads in pulseuadio, which makes reading a bit
> >>>> confuse.
> >>>> this patch can print each pthread's id.
> >>>
> >>> Wouldn't it be easier to understand if the thread name was used? We
> >>> typically rely on thread names to understand what goes on with
> >>> ftrace/pytimechart, I would think this is similar here. I would rather
> >>> see a
> >>> log with "alsa-sink" rather than "PID 6779", it'd also make log comparison
> >>> and analysis easier.
> >>
> >> Yup I agree (in an ideal world we'd name the thread by sink index too...
> >> (i.e. "alsa-sink 0")
> >
> > Hi Col,
> >
> > Do you think it's better to invoke pa_thread_new("alsa-sink 0", func, u)
> > or adding another index after the plain name? (e.g.
> > pa_thread_new("alsa-sink", index, func, u))
>
> I've not looked at the code, but if we know the sink index by this stage
> (I'm not sure we do?) then yes that could be helpful.
Not for now. at pa__init() stage, we don't know the module's index,
however, it can be supported via attached patch.
>
> Pierre will probably know if this is practically useful tho'. I suppose
> in most cases testing and probing will be done with only one sink anyway
> so there is no doubt which one owns the thread :p
I'm justing looking around on this mailing list and would like to get my
hands dirty. :D So either way is OK for me.
--
guanqun
>From 524829788c5b5a9aa34986fbee163326f6f09267 Mon Sep 17 00:00:00 2001
From: Lu Guanqun
Date: Mon, 8 Aug 2011 10:22:50 +0800
Subject: [PATCH] module: shuffle the sequence of acquiring the module index
With this change, we can get the module index in pa__init() function of a
module.
Signed-off-by: Lu Guanqun
---
src/pulsecore/module.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/pulsecore/module.c b/src/pulsecore/module.c
index 8b3ff8f..73f1208 100644
--- a/src/pulsecore/module.c
+++ b/src/pulsecore/module.c
@@ -64,6 +64,7 @@ pa_module* pa_module_load(pa_core *c, const char *name, const
char *argument) {
m->argument = pa_xstrdup(argument);
m->load_once = FALSE;
m->proplist = pa_proplist_new();
+m->index = PA_IDXSET_INVALID;
if (!(m->dl = lt_dlopenext(name))) {
pa_log("Failed to open module \"%s\": %s", name, lt_dlerror());
@@ -106,14 +107,14 @@ pa_module* pa_module_load(pa_core *c, const char *name,
const char *argument) {
m->core = c;
m->unload_requested = FALSE;
+pa_assert_se(pa_idxset_put(c->modules, m, &m->index) >= 0);
+pa_assert(m->index != PA_IDXSET_INVALID);
+
if (m->init(m) < 0) {
pa_log_error("Failed to load module \"%s\" (argument: \"%s\"):
initialization failed.", name, argument ? argument : "");
goto fail;
}
-pa_assert_se(pa_idxset_put(c->modules, m, &m->index) >= 0);
-pa_assert(m->index != PA_IDXSET_INVALID);
-
pa_log_info("Loaded \"%s\" (index: #%u; argument: \"%s\").", m->name,
m->index, m->argument ? m->argument : "");
pa_subscription_post(c,
PA_SUBSCRIPTION_EVENT_MODULE|PA_SUBSCRIPTION_EVENT_NEW, m->index);
@@ -137,6 +138,9 @@ pa_module* pa_module_load(pa_core *c, const char *name,
const char *argument) {
fail:
if (m) {
+if (m->index != PA_IDXSET_INVALID)
+pa_idxset_remove_by_index(c->modules, m->index);
+
if (m->proplist)
pa_proplist_free(m->proplist);
--
1.7.6
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log
On Sat, Aug 06, 2011 at 07:10:16PM +0800, Colin Guthrie wrote:
> 'Twas brillig, and Pierre-Louis Bossart at 05/08/11 16:24 did gyre and
> gimble:
> >> there're multiple pthreads in pulseuadio, which makes reading a bit
> >> confuse.
> >> this patch can print each pthread's id.
> >
> > Wouldn't it be easier to understand if the thread name was used? We
> > typically rely on thread names to understand what goes on with
> > ftrace/pytimechart, I would think this is similar here. I would rather see a
> > log with "alsa-sink" rather than "PID 6779", it'd also make log comparison
> > and analysis easier.
>
> Yup I agree (in an ideal world we'd name the thread by sink index too...
> (i.e. "alsa-sink 0")
Hi Col,
Do you think it's better to invoke pa_thread_new("alsa-sink 0", func, u)
or adding another index after the plain name? (e.g.
pa_thread_new("alsa-sink", index, func, u))
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log
On Fri, Aug 05, 2011 at 10:24:17PM +0800, Pierre-Louis Bossart wrote: > > there're multiple pthreads in pulseuadio, which makes reading a bit > > confuse. > > this patch can print each pthread's id. > > Wouldn't it be easier to understand if the thread name was used? We > typically rely on thread names to understand what goes on with > ftrace/pytimechart, I would think this is similar here. I would rather see a > log with "alsa-sink" rather than "PID 6779", it'd also make log comparison > and analysis easier. > -Pierre How about the patch something like below? :) It displays the thread name instead of thread id. > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >From 25659dfbd3fa8a77bd9d015235817595a2fe1ac1 Mon Sep 17 00:00:00 2001 From: Lu Guanqun Date: Mon, 8 Aug 2011 10:24:13 +0800 Subject: [PATCH] log: add thread name This patch displays thread name in the log, that would be more descriptive. It improves Xingchao (xingchao.w...@intel.com)'s patch which shows thread id. Signed-off-by: Lu Guanqun --- src/pulsecore/log.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pulsecore/log.c b/src/pulsecore/log.c index 1303814..a5a9162 100644 --- a/src/pulsecore/log.c +++ b/src/pulsecore/log.c @@ -302,9 +302,9 @@ void pa_log_levelv_meta( pa_vsnprintf(text, sizeof(text), format, ap); if ((_flags & PA_LOG_PRINT_META) && file && line > 0 && func) -pa_snprintf(location, sizeof(location), "[%s:%i %s()] ", file, line, func); +pa_snprintf(location, sizeof(location), "[%s][%s:%i %s()] ", pa_thread_get_name(pa_thread_self()), file, line, func); else if ((_flags & (PA_LOG_PRINT_META|PA_LOG_PRINT_FILE)) && file) -pa_snprintf(location, sizeof(location), "%s: ", pa_path_get_filename(file)); +pa_snprintf(location, sizeof(location), "[%s]%s: ", pa_thread_get_name(pa_thread_self()), pa_path_get_filename(file)); else location[0] = 0; -- 1.7.6 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] how's fighting rewind going?
On Sat, Jun 18, 2011 at 12:49:33AM +0800, David Henningsson wrote: > PulseAudio has some packet overhead, and rewinding has some extra > overhead. Here's how it gets stuck: > > When PulseAudio's buffer is empty, and a new packet comes in that is to > be played immediately, that causes a rewind. Now assume this packet is > so small, that by the time PulseAudio gets to process the next packet, > the buffer is empty again, because the few samples added have already > been played. Then a new rewind will be triggered, and this goes on and > on until the kernel kills PA for having used too much CPU with realtime > priority. Thanks for the info. The phenomenon here is it will rewind for ever, while the CPU load is not very high. Maybe my test time should last longer. > > So, the time taken to process the packet, including the rewind, and > possibly also time stolen by other processes etc, must be less than the > time taken to play back the samples that the packet carries. (And > probably with a decent margin.) > > What my PA patch does is to try to merge several packets that PA has in > its processing queue so it will only do rewind once. > What my GStreamer patch should do, is to remove some strange packet > splitter in the pulsesink end, but I might have misunderstood something > since it got reverted. It did however help me, and quite a few other > people as well, so it's still in Ubuntu. So is it supposed to be the bigger buffer in pulsesink, the less number of rewind it will encounter? > > -- > David Henningsson, Canonical Ltd. > http://launchpad.net/~diwic -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] how's fighting rewind going?
On Fri, Jun 17, 2011 at 03:43:53PM +0800, David Henningsson wrote: > On 2011-06-17 09:13, Lu Guanqun wrote: > > Hi David, > > > > On Fri, Jun 17, 2011 at 02:31:41PM +0800, David Henningsson wrote: > >> On 2011-06-17 02:21, Lu Guanqun wrote: > >>> Hi David, > >>> > >>> How's your fighting rewind going? > >>> > >>> Now, I find there's a rewind flood in my environment, and it's doing a > >>> rewrite rewind all the times. At the time of rewinding, the write index > >>> is less than the read index. > >>> > >>> Do you have any idea what's going on? I'm only seeing this when I'm > >>> viewing an 1080p MP4 file. > >>> > >>> Thanks! > >> > >> Hi Lu, > >> > >> My patches has been optimisations so far, which means that it's reducing > >> the amount of rewinds rather than eliminating them. With a slow enough > >> computer (for Intel, the Atom comes to mind), or lots of other things to > >> do for that computer (such as viewing an 1080p file?), the rewind flood > >> thing can still happen. > > > > Oh, man, you totally got me. :) I'm playing 1080p on an Atom based machine. > > I find the rewind flood on this platform. For 480p video, it works quite > > fine. > > > >> > >> What client are you using to connect to PulseAudio? For gstreamer based > >> clients, my gstreamer patch was first applied upstream, then reverted > >> for reasons I don't fully understand. Applying it is likely to help > >> against rewinds. See bug https://bugzilla.gnome.org/show_bug.cgi?id=641072 > > > > Yes, I used gstreamer clients. FYI. The two patches on pulesaudio are > > already applied. However, no matter when I applied the gstreamer patch, > > the rewind flood still can be seen. > > > > As you said, you're doing optimizations. Is there a way to fully solve > > this issue, or this is just a mission impossible per your understanding? > > Nothing is impossible, the impossible just takes slightly longer to fix :-) Definitely. :) > > Lately I've been thinking that we should implement some kind of > ratelimit to rewinding as well. Something like; if we've done 10 rewinds > during the latest second, block rewinds for the upcoming second. That > would give a "hickup" (likely temporary silence), but not complete > brokenness. > In combination with the existing patches, I believe that would give > sufficient protection. I haven't figured out, however, what would be the > right numbers for a particular machine. > > The best thing you can do for now, however, is to make sure the client > sends large packets. I e, rather one packet per second with one second > of sample data in it, than a hundred packets with 10 ms of sample data > in it. Thanks for the idea, let me try on this direction. BTW: is smaller packet the root cause of infinite rewrite rewind? Could you elaborate the overall process in a little more detail? It makes me think it's due to the wrong corporation between pulseaudio and gstreamer client. > > > -- > David Henningsson, Canonical Ltd. > http://launchpad.net/~diwic -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] how's fighting rewind going?
Hi David, On Fri, Jun 17, 2011 at 02:31:41PM +0800, David Henningsson wrote: > On 2011-06-17 02:21, Lu Guanqun wrote: > > Hi David, > > > > How's your fighting rewind going? > > > > Now, I find there's a rewind flood in my environment, and it's doing a > > rewrite rewind all the times. At the time of rewinding, the write index > > is less than the read index. > > > > Do you have any idea what's going on? I'm only seeing this when I'm > > viewing an 1080p MP4 file. > > > > Thanks! > > Hi Lu, > > My patches has been optimisations so far, which means that it's reducing > the amount of rewinds rather than eliminating them. With a slow enough > computer (for Intel, the Atom comes to mind), or lots of other things to > do for that computer (such as viewing an 1080p file?), the rewind flood > thing can still happen. Oh, man, you totally got me. :) I'm playing 1080p on an Atom based machine. I find the rewind flood on this platform. For 480p video, it works quite fine. > > What client are you using to connect to PulseAudio? For gstreamer based > clients, my gstreamer patch was first applied upstream, then reverted > for reasons I don't fully understand. Applying it is likely to help > against rewinds. See bug https://bugzilla.gnome.org/show_bug.cgi?id=641072 Yes, I used gstreamer clients. FYI. The two patches on pulesaudio are already applied. However, no matter when I applied the gstreamer patch, the rewind flood still can be seen. As you said, you're doing optimizations. Is there a way to fully solve this issue, or this is just a mission impossible per your understanding? > > -- > David Henningsson, Canonical Ltd. > http://launchpad.net/~diwic -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth HSP sink is more likely to cause buffer underrun when moving a live stream to it from ALSA, how to ask application to write more data?
On Fri, Jun 17, 2011 at 10:36:34AM +0800, Lin, Mengdong wrote:
> I found when moving a running live stream (of Gtalk) from an ALSA sink
> to a new created Bluetooth HSP sink, buffer underruns and rewind flood
> can happen and so I can no longer hear the voice from the other side.
> I抳e tried the following methods but still cannot avoid buffer
> underrun 100%. Could anyone share any idea about other methods?
Hi Amanda,
Though I me it in a different situation, but I've met this: one underrun
then rewind crazily, then no sound can be heard.
Generally, the read index should be less than the write index of sink's
memblockq. But after the underrun, the read index becomes larger than
the write index and then cause the rewrite rewind.
However, I've no idea how to overcome it right now.
>
> Here are the methods I tried:
>
> 1. Using the application original requested latency when moving sinks,
> with patch of Arun
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-June/010291.html
>
> But, I found the original latency (200ms) is still not enough to overcome
> excessive underrun. After I increase the audio latency to 500ms, there are no
> excessive underruns for most time. But not 100% safe.
>
>
>
> 2. Force the implementor to rewind by itself when underrun happens.
> (original audio latenty 200ms is used on moving the sink)
>
> I found for the BT HSP sink cannot really rewind, because It does not
> implement 搑equest_rewind? function on the sink and its
> 搒ink->thread_info.max_rewind? is 0.
>
> So I modified handle_seek() function in the 損rotocol-native.c? to let the
> implement rewind by itself:
>
>
>
> if (indexw < indexr) {
>
> /* OK, the sink already asked for this data, so
>
> * let's have it usk us again */
>
>
>
> pa_log_debug("Requesting rewind due to rewrite.!");
>
> pa_sink_input_request_rewind(s->sink_input, (size_t) (indexr -
> indexw), TRUE, FALSE, FALSE);
>
>
>
>
>
> + /* amanda: to fight BT underrun */
>
> + if(s->sink_input->sink)
>
> +{
>
> +pa_sink * sink = s->sink_input->sink;
>
> +if(!sink->request_rewind && !sink->thread_info.max_rewind)
>
> +{
>
> +/* the sink cannot handle rewind, implementor rewind by
> itself */
>
> + sink_input_process_rewind_cb(s->sink_input, (size_t)
> (indexr - indexw));
>
> + }
>
> +}
>
>
>
> }
>
> Unfortunately, excessive rewind cannot be avoided and the voice is frequently
> interrupted.
>
>
> What other method can I try? How to ask the application to feed more data?
> Does the application write data during sink moving so that there are some
> data buffered for the destination sink?
>
> Great thanks!
> Amanda
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] how's fighting rewind going?
Hi Sean, I saw your post here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009834.html you mentioned: """ Some amount of rewinds are normal. Especially when the server first starts up, or when the amount of latency demanded by an application is very low while system load is high. But excessive rewinds can be due to a driver bug in ALSA (this would have to be specific to your hardware since I can't reproduce the issue here on Maverick). I like to compare it to an anti-lock break system: if it engages at the right time, it's useful, but if it engages erroneously it can be dangerous. """ Now I have a similar crazy rewind, I want to know what kind of ALSA bug it's possible in your mind? So that I can debug further in this direction. On Fri, Jun 17, 2011 at 08:21:22AM +0800, Lu Guanqun wrote: > Hi David, > > How's your fighting rewind going? > > Now, I find there's a rewind flood in my environment, and it's doing a > rewrite rewind all the times. At the time of rewinding, the write index > is less than the read index. > > Do you have any idea what's going on? I'm only seeing this when I'm > viewing an 1080p MP4 file. > > Thanks! > -- > guanqun > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] how's fighting rewind going?
Hi David, How's your fighting rewind going? Now, I find there's a rewind flood in my environment, and it's doing a rewrite rewind all the times. At the time of rewinding, the write index is less than the read index. Do you have any idea what's going on? I'm only seeing this when I'm viewing an 1080p MP4 file. Thanks! -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to check audio sample data to a bluetooth sink?
On Mon, May 30, 2011 at 11:10:11PM +0800, Lin, Mengdong wrote: > Great thanks, Tanu! I can capture the sink's data as you suggested. > > But I have a new question: > > > since the streams have to be resampled before they can > > be mixed into one stream, the data that you get from the monitor source > > is resampled to the sink's sample rate. > > > > Now I suspect the resampling is problematic, how to check the data from a > single input stream before resampling? Hi Amanda, What do you mean by "resampleing is problematic"? What's the `resample method` for your sink inputs? > > Thanks > Amanda > > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
