[pulseaudio-discuss] module-role-cork and mp3s

Sat Aug 15 08:05:36 PDT 2015

On 15.08.2015 16:46, Mikhail Morfikov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2015-08-15 14:36, Georg Chini wrote:
>> On 14.08.2015 11:46, Georg Chini wrote:
>>> On 14.08.2015 10:51, Mikhail Morfikov wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> On 2015-08-14 10:18, Georg Chini wrote:
>>>>> On 14.08.2015 09:33, Mikhail Morfikov wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA512
>>>>>>
>>>>>> On 2015-08-14 01:14, Georg Chini wrote:
>>>>>>> On 13.08.2015 23:29, Mikhail Morfikov wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA512
>>>>>>>>
>>>>>>>> On 2015-08-13 18:49, Georg Chini wrote:
>>>>>>>>> On 13.08.2015 14:58, Tanu Kaskinen wrote:
>>>>>>>>>> On Thu, 2015-08-13 at 10:50 +0200, Mikhail Morfikov wrote:
>>>>>>>>>>> I have two streams one phone and one video/audio, and when I set the
>>>>>>>>>>> following:
>>>>>>>>>>>
>>>>>>>>>>> load-module module-role-ducking trigger_roles=phone
>>>>>>>>>>> ducking_roles=music,video volume=60%
>>>>>>>>>>>
>>>>>>>>>>> and I start playing an mp3, the volume is lowered to 60% and that's
>>>>>>>>>>> fine. Each time a new mp3 is being played the volume doesn't change,
>>>>>>>>>>> which is also a good thing.
>>>>>>>>>>>
>>>>>>>>>>> There's another module module-role-cork and when it's enabled (also
>>>>>>>>>>> commenting out the line above), it acts a little bit strange. When I
>>>>>>>>>>> start the phone stream, the mp3 is muted, and that's expected, but
>>>>>>>>>>> when
>>>>>>>>>>> another mp3 starts to play, the sound appears.
>>>>>>>>>>>
>>>>>>>>>>> Should that happen?
>>>>>>>>>> Ideally that shouldn't happen, but currently we have a bit limited
>>>>>>>>>> support for managing corking. Currently applications are required to
>>>>>>>>>> cooperate when we want to cork them. module-role-cork sends a cork
>>>>>>>>>> request to an application, and the application will then obey that
>>>>>>>>>> request (or not, but in your case not obeying the request is not the
>>>>>>>>>> problem). To make this work on new streams too, module-role-cork should
>>>>>>>>>> send the cork request also when a new stream appears, which it
>>>>>>>>>> currently doesn't do. It could very well do that, so patches welcome!
>>>>>>>>>>
>>>>>>>>>> Sending a cork request after a new stream has appeared isn't quite
>>>>>>>>>> optimal, since the beginning of the stream may already hit the speakers
>>>>>>>>>> before the corking happens, but that would still be better than the
>>>>>>>>>> current behaviour.
>>>>>>>>>>
>>>>>>>>>> It would be good to have "server-side corking" that wouldn't require
>>>>>>>>>> cooperation from applications. That's a bit more complicated to
>>>>>>>>>> implement.
>>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> you could try if my patches
>>>>>>>>> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23189
>>>>>>>>> solve the problem because the patches combine module-role-cork
>>>>>>>>> and module-role-ducking (and I believe they should mute/cork a stream
>>>>>>>>> when it appears).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>                 Georg
>>>>>>>>> _______________________________________________
>>>>>>>>> pulseaudio-discuss mailing list
>>>>>>>>> pulseaudio-discuss at lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>>>>>> I've tested the patches, but nothing has changed.
>>>>>>>>
>>>>>>> That's strange because with the patches both modules share the
>>>>>>> same code. So I would have expected that they behave equally.
>>>>>>> Can you check if there is any difference between the two cases by
>>>>>>> running pulseaudio with debugging? There should be a line in the
>>>>>>> log each time the module interacts with a stream.
>>>>>>>
>>>>>>> Georg
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> pulseaudio-discuss mailing list
>>>>>>> pulseaudio-discuss at lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>>>> I've compared the debug logs in both cases (with and without patches)
>>>>>> and checked whether they're different in any point. There are 3
>>>>>> occurrences of stream-interaction.c in the log with patches:
>>>>>>
>>>>>> D: [pulseaudio] stream-interaction.c: Using role 'phone' as trigger role.
>>>>>> D: [pulseaudio] stream-interaction.c: Using roles 'music' and 'video' as cork roles.
>>>>>> ...
>>>>>> D: [pulseaudio] stream-interaction.c: Found a 'phone' stream that corks/mutes a 'video' stream.
>>>>>>
>>>>>> And there's also:
>>>>>>
>>>>>> D: [pulseaudio] sink-input.c: The mute of sink input 0 changed from no to yes.
>>>>>>
>>>>>> And that's it. I can provide you with the full logs if you needed them.
>>>>>>
>>>>> I was rather thinking about a comparison between module-role-cork
>>>>> and module-role-ducking with the patches because they behave differently
>>>>> even though the code is exactly the same. I would expect, that when you
>>>>> compare the log messages there should be no difference except that it
>>>>> says "cork" for one module and "duck" for the other.
>>>>>
>>>>> One reason I can think of why there is a problem with role-cork but not with
>>>>> role-ducking is that the new stream might still be corked when the sink_input
>>>>> is put. So role-cork sees the stream as corked and does nothing but the
>>>>> application uncorks the stream at a later time.
>>>>>
>>>>> Regards
>>>>>                Georg
>>>>> _______________________________________________
>>>>> pulseaudio-discuss mailing list
>>>>> pulseaudio-discuss at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>> I hadn't tested module-role-ducking with patches before, but it looks like that
>>>> both modules act in the same way with patches. I mean, when I use:
>>>>
>>>> load-module module-role-ducking trigger_roles=phone ducking_roles=music,video volume=60%
>>>>
>>>> it lowers the volume to 60% when TS3 starts to capture, but when another mp3
>>>> is being played, the volume backs to 100%. Something like "unmute" in the case
>>>> of module-role-cork .
>>> Thanks for letting me know. I will look into this and hope to send another
>>> series of patches some time this weekend.
>>>
>> Hi Mikhail,
>>
>> the problem was exactly what I described above. I just posted a patch on top
>> of my previous series. See also comments in the patch. Could you please test?
>> Expected result would be that module-role-ducking acts correctly while with
>> module-role-cork a new stream is only muted.
>> I could cork a stream when it changes its state to uncork, but this would mean
>> that you can no longer uncork a stream manually if it was corked by module-role-cork.
>>
>> @Tanu: Is there something like a "cork counter" in PA which keeps track of
>> multiple corks for the same stream and only releases the cork if the counter
>> goes to zero? If not should something like that be added?
>>
>> Regards
>>               Georg
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> I've tested the new patch and both modules work in the way I wanted. I mean,
> when set:
>
> load-module module-role-cork
>
> the amarok is muted when TS3 starts to capture and when amarok plays another
> mp3, it's still muted.
>
> And the same with:
>
> load-module module-role-ducking trigger_roles=phone ducking_roles=music,video volume=60%
>
> where the volume is lowered to 60% and stays at this level till TS3 stops
> capturing.
>
> I have one question concerning the manually unmuted applications. I'm able
> to unmute amarok, and it plays mp3 till its end, but the next mp3 will be muted.
> Is there a way to fix this so the apps that are manually unmuted would stay
> in that way? At least to the moment when you mute them again, also manually.
>
>
Thank you for testing. Regarding your question: I think it is not possible
because amorak stops one stream and then starts the next. There is no
way for the module to know that the new stream that is starting originates
from an application where the previous stream was manually unmuted.
So every time a new stream starts it will be treated according to the rules
of the module.

Georg