[pulseaudio-discuss] [PATCH 0/5] Remail of "Various small fixes"

Colin Guthrie gmane at colin.guthr.ie
Thu Jan 13 07:40:04 PST 2011


Nice thanks for this Jyri. I was actually going to ping you to make sure
you got my comments as I don't think I CC'ed you directly, just replied
to the list.

Anyway, I'll grab these in... likely over the weekend as I've got a few
things piling up now!

Col

'Twas brillig, and oku at iki.fi at 13/01/11 14:44 did gyre and gimble:
> From: Jyri Sarha <jyri.sarha at nokia.com>
> 
> On Wed, 22 Dec 2010, Colin Guthrie wrote:
>> 'Twas brillig, and oku at iki.fi at 20/12/10 16:47 did gyre and gimble:
> ...
>>>
>>> +    pa_xfree(l->name);
>>>      pa_xfree(l);
>>>  }
>>
>> The assert on l->name on free is probably overkill as pa_xfree will
>> silently ignore nulls anyway, so it would do no harm. That and it's
>> pretty much impossible for l->name to be null anyway...
>>
>> OK to drop that assert?
> 
> Assert dropped.
> 
> On Wed, 22 Dec 2010, Colin Guthrie wrote:
> 
>> 'Twas brillig, and oku at iki.fi at 20/12/10 16:47 did gyre and gimble:
>>> From: Jyri Sarha <jyri.sarha at nokia.com>
> ...
>>>  }
>>
>> While I'm not 100% sure here, I think the mixer_callback is needed when
>> u->sink->flags & PA_SINK_HW_MUTE_CTRL, but you now only activate this
>> when u->sink->flags & PA_SINK_HW_VOLUME_CTRL. While it's quite unlikely
>> that some h/w exsist that has PA_SINK_HW_MUTE_CTRL but not
>> PA_SINK_HW_VOLUME_CTRL I think this should either be set unconditionally
>> (as before) or at least within an if block that checks for either flag.
>>
> 
> Yes, you are right about that. I changed the condition to check for the
> both flags.
> 
> I also rebased the patches against the lastest and run couple of brief tests
> with it.
> 
> Cheers,
> 	Jyri
> 
> The old cover letter contents:
>> These are all pretty obvious fixes, but maybe the "core: Use
>> volume_change_safety_margin when rewinding sync-volume events"
>>
>> A volume change always triggers a rewinding on the sink. This is
>> sometimes a problem when the flat-volume is turning HW volume down and
>> compensating with SW volume. The rewind gets the samples with the new
>> SW-volume very close to HW-pointer and we may not have enough headroom
>> to process rewinding on the streams and monitor source before the
>> first samples are played out.
>>
>> With the patch I first of all rewind the volume changes differently
>> depending on whether volume is going up or down. The volume events are
>> rewound as soon as possible after DMA-buffer rewinding and immediately
>> after it there is a check if we should write something to HW.
> 
> Jyri Sarha (5):
>   core: Change sematics of pa_flist_new_with_name() (v1.1)
>   core: Use volume_change_safety_margin when rewinding sync-volume
>     events
>   core: Use pa_sink_get_latency_within_thread() in sync-volume code
>   alsa-sink: Fix double use of string
>   alsa-sink: Don't assume we were able to enable hw-volume or
>     sync-volume (v1.1)
> 
>  src/modules/alsa/alsa-sink.c |   56 +++++++++++++++++++++--------------------
>  src/pulsecore/flist.c        |    4 ++-
>  src/pulsecore/flist.h        |    4 +-
>  src/pulsecore/sink.c         |   33 +++++++++++++-----------
>  4 files changed, 52 insertions(+), 45 deletions(-)


-- 

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/]




More information about the pulseaudio-discuss mailing list