On 05/30/2013 01:38 PM, Tanu Kaskinen wrote: > 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? Perhaps: * Mixer improvements for some laptops with TRRS headset jacks. >>> + * Capture support fixed for Logitech B530 USB headset. And this could be changed to "Capture support fixed for Logitech B530 USB headset and Focusrite Scarlett 2i2", because one of the patches was about that. > >>> + 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." > I'm okay with your version. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
