[pulseaudio-discuss] Problem with USB sound card - clicks and pops on re-open

[Christian Iversen]

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
Christian Iversen