Re: [pulseaudio-discuss] volume ramping
Oh great, so it will be merged back into a branch as a new feature. Is there any place to push patches I've made against it somewhere, or should i just wait until its merged back in? Thanks On Mon, May 16, 2011 at 7:22 PM, Arun Raghavan arun.ragha...@collabora.co.uk wrote: On Mon, 2011-05-16 at 18:21 -0700, Baek Chang wrote: Hi, There used to be some test/sample code that did volume ramping on pulseaudio git source. Recently it has been taken out. Any idea as to why, the revert commits did not mention a reason. I've been testing it out and it seems stable, I did have to change some of the logic and code to get it working without glitches. You can see discussion about this in the last IRC meeting logs (1 d) at: http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-meeting.2011-02-24-17.08.html -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- -baeksanchang ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] volume ramping
'Twas brillig, and Baek Chang at 17/05/11 18:13 did gyre and gimble: Oh great, so it will be merged back into a branch as a new feature. Is there any place to push patches I've made against it somewhere, or should i just wait until its merged back in? There isn't a feature branch for this yet as I'm not sure Lennart was really happy with the approach he had (I can't remember the details, either he's not happy with the approach or he didn't have time to properly tidy it up) - either way there is no where just now to apply patches on top, but we could likely introduce a feature branch for this. That said, it's likely going to be quite hard to bring the feature back with subsequent changes in volume code in the mean time (dealing with flat volumes is tricky to say the least!). But obviously we don't want to loose your work so perhaps Arun or even Lennart can make some suggestions in this regard? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Volume ramping
On 22 April 2010 23:18, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Jason Taylor at 22/04/10 11:34 did gyre and gimble:
Is there a reason you can't ramp volume from daemon introspection
http://0pointer.de/lennart/projects/pulseaudio/doxygen/introspect_8h.html
pa_context_set_sink_input_volume_with_ramping ?
IIRC volume ramping was implemented recently with some changes from IIRC
Intel.
I believe it's only used internally (e.g. from a module context) and I'm
not sure if it's ever been intended to export it or not.
I can't think off hand if there would be a problem exporting it, but
there may be conditions that I've not thought off.
Looking at the code sink_input.c
void pa_sink_input_set_volume(pa_sink_input *i, const pa_cvolume
*volume, pa_bool_t save, pa_bool_t absolute) {
/* test ramping - return pa_sink_input_set_volume_with_ramping(i,
volume, save, absolute, 2000 * PA_USEC_PER_MSEC); */
return pa_sink_input_set_volume_with_ramping(i, volume, save, absolute, 0);
}
So ramp code is actually being used already theres just not a way of
setting the number of seconds at the moment
Chances of code being accepted to add the option?
Cheers
--
Weekends don't count unless you spend them doing something completely
pointless. - Calven
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Volume ramping
'Twas brillig, and Jason Taylor at 22/04/10 11:34 did gyre and gimble: Is there a reason you can't ramp volume from daemon introspection http://0pointer.de/lennart/projects/pulseaudio/doxygen/introspect_8h.html pa_context_set_sink_input_volume_with_ramping ? IIRC volume ramping was implemented recently with some changes from IIRC Intel. I believe it's only used internally (e.g. from a module context) and I'm not sure if it's ever been intended to export it or not. I can't think off hand if there would be a problem exporting it, but there may be conditions that I've not thought off. 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] Volume Ramping Updated Patch
Hi, I sent out a refined patch for volume ramping according to suggestions from Lennart, but the mail is too big so I got the following info: Your mail to 'pulseaudio-discuss' with the subject Volume Ramping Updated Patch Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 310324 bytes with a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: Could someone kindly approve the mail? Thanks a lot! Best Regards, Zheng, Huan(ZBT) OTC/SSD/SSG Intel Asia-Pacific Research Developement Ltd Tel: 021-6116 6435 Inet: 8821 6435 Cub: 3W035 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Volume Ramping Updated Patch
'Twas brillig, and Zheng, Huan at 15/07/09 09:04 did gyre and gimble: Could someone kindly approve the mail? I'm afraid I don't have the necessary permissions here :( Perhaps you should consider one of the following options: 1. Post a git format-patch version of your changes as sepearate emails (e.g. each commit is a separate email). git email helps you do this. 2. Put your changes in a pulseaudio clone via a free git hosting service such as gitorious or git-hub. That way Lennart can add a remote and review the changes that way. Lennart is currently on holiday, but he'll be back in a week or so. Sorry I can't be more helpful. 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] volume ramping
On Mon, 15.12.08 17:12, Baek Chang (baek...@ccrma.stanford.edu) wrote: Sorry for the late response, I were to utilize a ramping function to process a block of audio in a sink-input, where should this be called? I tried using inserting a ramping routine on a sink-input within pa_sink_input_peek(), in sink-input.c This seems to give me strange results. Any suggestions on where I could process the audio data of individual sink-inputs before it gets mixed down into a single sink? pa_sink_input_peek() is the right place. But please note that you should advance you state only in pa_sink_input_drop()! The background for this: the render code first calls _peek() for all streams. They might return memory blocks of different sizes. We mix all blocks into a block that has the smallest size of the ones we got. Then we tell all streams with _drop() how many bytes have actually been used. That means: a. If _peek() is called twice in a row without a _drop() in between no samples have been used -- the stream should hence return the same data both times. b. If _peek() returns 200 bytes but _drop() gets only 100 passed, then you should advance your state only by 100, not by 200! Finally, in some situations we might need to rewind the buffers, so that the data can be read again from the streams. The streams are informed about that via pa_sink_input_process_rewind(). So, you need to patch _peek(), _drop() and _process_rewind(). In the first function you apply your ramping. In the second function you advance your state. In the third function you rewind your state. I plan to add new hooks at these three new places so that modules can modify the sound data in arbitrary ways without any further changes in the main code. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 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] volume ramping
On Thu, 11.12.08 09:56, Baek Chang (baek...@ccrma.stanford.edu) wrote: What is the proper way to do volume ramping in pulse audio to avoid clicking when changed the volume? I wrote a module to callback and change the volume in small incremental steps, but it seems that pulse seems to apply the volume changes on the audio buffer as a whole. Does pulseaudio take a volume command, and then process the one audio buffer with that set volume? I'm using a buffer size of 4096 at 44100Hz, so it is about 10mS. So how would I go about ramping the volume, in say about 15 mS? Volumes are applied block-by-block. The Block size is variable and depends on the sound device and the application used. I wrote some code to implement volume envelopes for this. The code is there, it's even included in the tarball. But it's not hooked up. And until I finish that I fear, no: we cannot do volume ramping. Sorry, Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
