[pulseaudio-discuss] [PATCH v2] Add a news file

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Thu May 30 04:38:59 PDT 2013


On Thu, 2013-05-30 at 13:03 +0200, David Henningsson wrote:
> On 05/30/2013 11:54 AM, Tanu Kaskinen wrote:
> > +  Hardware support changes:
> > +
> > +   * Both outputs of Native Instruments Traktor Audio 2 can now be
> > +     used simultaneously without any manual configuration.
> > +
> > +   * Various improvements for Intel HDA based sound cards.
> 
> This sounds very vague. What is this referring to?

It refers to the alsa-mixer fixes that you've done. I believe those
fixes are crucial for some hardware, so it makes sense to mention them
since the fixes enable new hardware (or some new functionality of
previously partially-working hardware), but I don't know the hardware
details, hence the vague wording. Can you suggest better wording? Or
should I drop this item?

> > +  Bug fix highlights:
> > +
> > +   * Quicker drains: in previous versions of PulseAudio, it could
> > +     sometimes take up to a few seconds after a stream finished
> > +     playing until pa_stream_drain() actually returned. This has now
> > +     been fixed, which also means that programs such as paplay will
> > +     end quicker after having finished playback.
> > +
> > +   * Issues with device handover to JACK were fixed. JACK should be
> > +     now able to reliably acquire the sound card while PulseAudio is
> > +     running.
> > +
> > +   * When converting between different channel maps, the remixing
> > +     can't result in clipping anymore. Streams that earlier could
> > +     potentially get clipped are now a bit quieter.
> 
> Btw, do you think the low-latency commits are worth mentioning? E g,
> 
>   * A bug caused PulseAudio to request data too late in low-latency 
> scenarios (unless minreq was specified by the client), causing dropouts. 
> If the total latency requested is below 80 ms, we now default to 
> requesting more data four times as often as the requested latency.
> 
> (feel free to rephrase)

I'd write a less detailed version:

"In certain low-latency scenarios PulseAudio used a bad algorithm to
decide when to ask clients to send more data. The algorithm has been
improved, resulting in fewer drop-outs in those scenarios."

-- 
Tanu



More information about the pulseaudio-discuss mailing list