[pulseaudio-discuss] Problem with USB sound card - clicks and pops on re-open
chrivers at iversen-net.dk
Tue May 21 07:01:59 PDT 2013
On 2013-05-14 08:50, David Henningsson wrote:
> On 05/13/2013 11:19 PM, Christian Iversen wrote:
>> On 2013-05-13 05:41, Arun Raghavan wrote:
>>> On Sun, 2013-05-12 at 17:18 +0200, Christian Iversen wrote:
>>>> Is there any way to have pulseaudio keep the device open at all times?
>>>> Or some other way to debug this?
>>> Disable the loading of module-suspend-on-idle in /etc/pulse/default.pa.
>>> I'm assuming you don't care about the resulting power consumption. :)
>> Ah, there is was! :)
>> Well, that's great. Thanks!
>> I don't think the Scarlett 2i2 really supports any meaningful power save
>> mode anyway. It's quite a low-power soundcard to begin with (powered
>> entirely by the USB bus).
> Not so low-power IMO, it takes about 2-3W of my battery when connected
> (only tested with phantom power on). I think it does that regardless of
> stream running or not, but have not really checked. (The direct monitor
> requires headphone amp and mic amps on anyway.)
I should have been clearer. I think there is, at best, only a very
slight amount of power saved by idling this card. But the effects to the
user are quite severe.
>> Anyway, even with the official driver for windows, this card has
>> terrible clicks and pops when starting up from suspend (or power off).
> Ok, good to know.
>> Does module-suspend-on-idle have a blacklist? It should! And this card
>> should be on it.
> There are other reasons for wanting to release the sound card when not
> actively using it - it makes compatibility with other apps easier, i e,
> everything that wants to use ALSA directly (except jack2 which has
> device reservation).
Point taken. But it's still quite annoying ;-)
>> What does pa use for identifying backends? I mean, if I wanted to
>> blacklist certain modules for a specific PCI or USB id, is that
>> something that is reasonably easy to do?
> Not currently, but it sounds very useful if we had a smart way of
> accomplishing this.
Agreed. Just like the kernel drivers have ample support for identifying
device quirks. I'm almost sure we could benefit from a similar scheme?
Med venlig hilsen
More information about the pulseaudio-discuss