Re: [pulseaudio-discuss] New feature in the works: volume sharing
On Tue, 2011-02-15 at 09:00 +0200, David Henningsson wrote: I have a question: how about the volume store/restore module? Will it store and restore the outermost sink's volume, the innermost one, or both? Another thing is the pick-up of volume/mute changes in the driver - at least that's done on the ALSA side. Will that then be pushed through in the other direction somehow, or...? Just trying to make sure you haven't missed anything :-) Excellent questions. The logic hasn't been used with module-device-restore, and volume changes from alsa have been disabled also. Changes from alsa are supposed to be supported, but that hasn't been tested. Volume restoring, however, seems to have been broken in the way that module-device-restore could in some situations restore the volume for a filter sink that uses volume sharing, which in my opinion should never happen. I'll make sure that this will be fixed. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New feature in the works: volume sharing
On Sun, 2011-02-13 at 22:05 +0200, Colin Guthrie wrote: With this push based approach, you do loose some individual granularity, but the net volume of the underlying h/w should be the same as your approach. What granularity would I lose? I think your suggested logic would be quite equivalent to the one that I originally proposed. The concern I have with the approach outlined, is that it adds complexity to the core and I'm not 100% sure how far the chain can go (e.g. can you have a filter-sink1-filter-sink2-filter-sink3-hw-sink pipeline? - with a push model this is possible). It's possible with the pull model too - the filter sinks are always traversed recursively. About complexity - I haven't done a thorough analysis of your suggestion, but I would guess that it would be a little bit simpler. There would still be a significant amount of added complexity in the core, though. I'll finish the patch using the original logic first, and if you want, I can probably do another version to see how much the push model will differ. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New feature in the works: volume sharing
'Twas brillig, and Tanu Kaskinen at 14/02/11 11:19 did gyre and gimble: On Sun, 2011-02-13 at 22:05 +0200, Colin Guthrie wrote: With this push based approach, you do loose some individual granularity, but the net volume of the underlying h/w should be the same as your approach. What granularity would I lose? I think your suggested logic would be quite equivalent to the one that I originally proposed. The concern I have with the approach outlined, is that it adds complexity to the core and I'm not 100% sure how far the chain can go (e.g. can you have a filter-sink1-filter-sink2-filter-sink3-hw-sink pipeline? - with a push model this is possible). It's possible with the pull model too - the filter sinks are always traversed recursively. About complexity - I haven't done a thorough analysis of your suggestion, but I would guess that it would be a little bit simpler. There would still be a significant amount of added complexity in the core, though. I'll finish the patch using the original logic first, and if you want, I can probably do another version to see how much the push model will differ. I don't really want to create extra work for you, I'm just genuinely unsure which would be considered a cleaner approach (or even if it really matters at all!!) Other opinions welcome :) 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] New feature in the works: volume sharing
On 2011-02-14 12:45, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 14/02/11 11:19 did gyre and gimble: On Sun, 2011-02-13 at 22:05 +0200, Colin Guthrie wrote: With this push based approach, you do loose some individual granularity, but the net volume of the underlying h/w should be the same as your approach. What granularity would I lose? I think your suggested logic would be quite equivalent to the one that I originally proposed. The concern I have with the approach outlined, is that it adds complexity to the core and I'm not 100% sure how far the chain can go (e.g. can you have a filter-sink1-filter-sink2-filter-sink3-hw-sink pipeline? - with a push model this is possible). It's possible with the pull model too - the filter sinks are always traversed recursively. About complexity - I haven't done a thorough analysis of your suggestion, but I would guess that it would be a little bit simpler. There would still be a significant amount of added complexity in the core, though. I'll finish the patch using the original logic first, and if you want, I can probably do another version to see how much the push model will differ. I don't really want to create extra work for you, I'm just genuinely unsure which would be considered a cleaner approach (or even if it really matters at all!!) Other opinions welcome :) I have a question: how about the volume store/restore module? Will it store and restore the outermost sink's volume, the innermost one, or both? Another thing is the pick-up of volume/mute changes in the driver - at least that's done on the ALSA side. Will that then be pushed through in the other direction somehow, or...? Just trying to make sure you haven't missed anything :-) -- 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] New feature in the works: volume sharing
On Thu, 2011-02-03 at 14:35 +0200, Tanu Kaskinen wrote: Hello, When we have a filter sink that does some processing, currently the benefits of the flat volume feature are not really available. That's because if you have a music player that is connected to the filter sink, the hardware sink doesn't have any idea of the music player's stream volume. In order to fix this, Pulseaudio 0.9.15 on Maemo 5 was hacked to implement a feature that was dubbed flat sink. The feature is still needed in Maemo 6 / MeeGo, and now we are finally trying to get it to upstream. The flat sink feature (better names welcome) works so that the filter sinks that want to avoid the previously described problem declare that they don't want to have independent volume, but they follow the master sink volume instead. Then the volume logic is changed so that the hardware sink calculates its real volume using also the streams connected to the filter sink in addition to the streams that are connected directly to the hardware sink. Basically we're trying to create an illusion that from volume point of view all streams are connected directly to the hardware sink, thus the stack of sinks collapses into a flat sink. I hope that sounds like something that can be merged to upstream. There will be several patches, and I just sent the first. The rest of the patches are not ready yet - I'll send them as I finish them. Update to the terminology: the flat sink feature shall be known as the volume sharing feature from now on. I think that's more descriptive, and doesn't get so easily mixed with the flat volume term. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
