Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com The first patch in the set gives sink implementor a possibility to synchronize HW and SW volume usage in IO-thread. The remaining patches implement the synchronization for the alsa-sink and add the necessary module parameters and defaults for them in daemon configuration. This code has been tested on Nokia's ARM based Meego platform, on i686 laptop and on amd64 desktop. Tanu Kaskinen has also reviewed the code. To check what this set of patches does, please try following: 1. play white noise in background on low volume: # pacat --fix-rate --volume=1 /dev/urandom 2. play a short transient stream with high volume while the noise plays in background: # dd if=/dev/zero count=200 | pacat --fix-rate --volume=65536 Without these patches on most hardware you hear an annoying snap either in the beginning or the end (sometimes both) of the transient stream.After applying the patch the snap should be gone or at least less audible. With a little fiddling of the parameters it should be possible to get rid of the snap on all hardware. The default parameters work well at least on my Lenovo T60 running Debian Squeeze and they should be good, maybe a bit conservative, for most HW out there. This patch is pretty much mandatory for proper usage of flat volume especially on less powerful HW. Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? Yes. On on non real-time OS and having less than accurate audio pipeline latency information this is a best effort task. Making this perfect would require HW support. So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Since implementing ramps on a HW mixer is really not applicable, this is the only solution that I can see and in practice it seems to work pretty well. I also think that most analog components have enough slowness in them which in effect causes a kind of ramp. BTW, ran the test from my previous mail, but using sine wave, and still I could not hear any snapping sound on my T60. Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume This is pretty much what my patch is doing, just in slightly different order: 1. Insert volume event to happen after sink's reported latency has expired (+ modifications). 2. rewind and adjust volume events 3. wait until volume event expires = rewind margin has passed 4. raise HW volume This approach works also with sinks that do not support rewinding (e.g. alsa-sink not using tsched). end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume Here you are forgetting that there may still be some samples left within the rewind margin. You should add the delay also there. In effect the both volume ups and downs become quite symmetrical. ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Well, I can't think how you get past wait until rewind margin has passed without having explicit delays. This code is really only chaning the way HW mixers are used. Ramping to SW volume could be implemented separately and it would not interfere with this patch in fact they would complement each other. But, hey please try out my patch. At least it solved the problem on N900 (yes the earlier version of the patch is on all N900s out there) and it works quite well on my both Linux boxes. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Ah, only after reading my reply from the mailing list I understand your concern. The sync-volume is really not only using some explicit timers, but it uses sinks latency information (got with pa_sink_get_latency_within_thread()) for timing the HW volume changes and adjust the timers when ever the DMA buffer is rewound. The parameters given are there only to compensate for timer and reported latency inaccuracy. The safety margin is for compensation dynamic inaccuracy and extra delay is there to compensate static errors. On most hardware extra delay should be set to zero. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? Yes. On on non real-time OS and having less than accurate audio pipeline latency information this is a best effort task. Making this perfect would require HW support. So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Since implementing ramps on a HW mixer is really not applicable, this is the only solution that I can see and in practice it seems to work pretty well. I also think that most analog components have enough slowness in them which in effect causes a kind of ramp. BTW, ran the test from my previous mail, but using sine wave, and still I could not hear any snapping sound on my T60. Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume This is pretty much what my patch is doing, just in slightly different order: 1. Insert volume event to happen after sink's reported latency has expired (+ modifications). 2. rewind and adjust volume events 3. wait until volume event expires = rewind margin has passed 4. raise HW volume This approach works also with sinks that do not support rewinding (e.g. alsa-sink not using tsched). end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume Here you are forgetting that there may still be some samples left within the rewind margin. You should add the delay also there. In effect the both volume ups and downs become quite symmetrical. ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Well, I can't think how you get past wait until rewind margin has passed without having explicit delays. This code is really only chaning the way HW mixers are used. Ramping to SW volume could be implemented separately and it would not interfere with this patch in fact they would complement each other. But, hey please try out my patch. At least it solved the problem on N900 (yes the earlier version of the patch is on all N900s out there) and it works quite well on my both Linux boxes. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Ah, only after reading my reply from the mailing list I understand your concern. The sync-volume is really not only using some explicit timers, but it uses sinks latency information (got with pa_sink_get_latency_within_thread()) for timing the HW volume changes and adjust the timers when ever the DMA buffer is rewound. The parameters given are there only to compensate for timer and reported latency inaccuracy. The safety margin is for compensation dynamic inaccuracy and extra delay is there to compensate static errors. On most hardware extra delay should be set to zero. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
From: Jyri Sarha jyri.sa...@nokia.com The first patch in the set gives sink implementor a possibility to synchronize HW and SW volume usage in IO-thread. The remaining patches implement the synchronization for the alsa-sink and add the necessary module parameters and defaults for them in daemon configuration. This code has been tested on Nokia's ARM based Meego platform, on i686 laptop and on amd64 desktop. Tanu Kaskinen has also reviewed the code. To check what this set of patches does, please try following: 1. play white noise in background on low volume: # pacat --fix-rate --volume=1 /dev/urandom 2. play a short transient stream with high volume while the noise plays in background: # dd if=/dev/zero count=200 | pacat --fix-rate --volume=65536 Without these patches on most hardware you hear an annoying snap either in the beginning or the end (sometimes both) of the transient stream. After applying the patch the snap should be gone or at least less audible. With a little fiddling of the parameters it should be possible to get rid of the snap on all hardware. The default parameters work well at least on my Lenovo T60 running Debian Squeeze and they should be good, maybe a bit conservative, for most HW out there. This patch is pretty much mandatory for proper usage of flat volume especially on less powerful HW. Cheers, Jyri ps. This is my second attempt to try to get this functionality in. This second version the patches is improved from the earlier and there is no need locks anymore. I can't think of any more improvements to it, so please let me know if I should still do something to get this integrated. Jyri Sarha (5): core: Add infrastructure for synchronizing HW and SW volume changes alsa: Take syncronized HW volume infra into use for alsa-sink udev-detect: Add sync_volume parameter daemon-conf: Add sync volume parameters to daemon-conf man: sync_volume parameters to manual page man/pulse-daemon.conf.5.xml.in | 26 src/daemon/daemon-conf.c|9 + src/daemon/daemon-conf.h|5 +- src/daemon/daemon.conf.in |4 + src/daemon/main.c |3 + src/modules/alsa/alsa-mixer.c | 117 ++- src/modules/alsa/alsa-mixer.h |9 +- src/modules/alsa/alsa-sink.c| 128 ++-- src/modules/alsa/alsa-source.c |2 +- src/modules/alsa/module-alsa-card.c |4 +- src/modules/alsa/module-alsa-sink.c | 10 +- src/modules/module-udev-detect.c| 18 ++- src/pulse/def.h |7 +- src/pulsecore/core.c|4 + src/pulsecore/core.h|3 + src/pulsecore/sink.c| 281 +-- src/pulsecore/sink.h| 97 ++-- 17 files changed, 672 insertions(+), 55 deletions(-) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
