Crude ALSA device selection.

[kilobyte]

This is a first stab at proper user-friendly ALSA device selection.

Leaves a lot to be wished for, but Works For Me™, and can be built upon.

[kilobyte]

Hi, could you please comment so I know I'm barking up the right tree?

Further improvements would include using a library or ioctls instead of scraping /proc/, device classification, plug detection, subdevice support, etc -- but researching/coding this is kind of a waste of time without some feedback from your side. Does what I'm proposing sound reasonable?

Out of 4 screen-attached computers I own, PulseAudio works adequately on 0. Here's one of examples.

[jonaski]

Isn't it better to use ALSA and snd_ctl_card_info() ?

[kilobyte]

@jonaski: yeah, that's the plan in the long run. I'm asking about behaviour Clementine's authors want though, not about implementation for now.

[hatstand]

I'm not sure we really care about ALSA but if you want to build this properly (i.e. without parsing /proc :-) and it's invisible to everyone who just uses pulseaudio then I'll merge it.

Incremental pull requests appreciated too.

[kilobyte]

I'm not sure we really care about ALSA

Out of 4 screen-attached computers I own, Pulse works adequately on 0:

• on one, there's a quiet noise that's perceivable only with no ambient sound (like, no cars outside, ie, at night, etc) but infuriating once it's hearable
• on one, an armhf laptop that's stuck on a 3.0 vendor kernel, Pulse causes a crash while ALSA works. Yeah, it's no direct fault of Pulse but the effect is the same.
• on one, there's no sound with Pulse, I did not bother investigating
• on one, you can hear it yourself (captured over analog jack, I did not bother adjusting loudness properly but the badness is obvious)

In all of these cases, problems are not specific to Clementine in any way (ie, exactly the same happens with mplayer, mpg123, etc). Thus, if without any specific needs I see a 4/4 fail rate on ordinary gear (ok, the armhf laptop probably doesn't count as ordinary), I guess a good part of other users also can't "just use pulseaudio".

if you want to build this properly (i.e. without parsing /proc :-) and it's invisible to everyone who just uses pulseaudio then I'll merge it.

Cool, would you prefer the library or ioctls? The former would be way cleaner and saner, the latter has no dependencies.

[hatstand]

Yeah, I get that it's your pet problem :-)

I think the library is fine; we probably link to it anyway via gstreamer.

[Anton-Latukha]

I'm not sure we really care about ALSA but if you want to build this properly (i.e. without parsing /proc :-) and it's invisible to everyone who just uses pulseaudio then I'll merge it.

Incremental pull requests appreciated too.

Since in Pulse audio goes through mixer, to allow multiple stream inputs (AFAIK even single audio stream always goes through the mixer).

With direct output to ALSA device - a bit-perfect stream goes into hardware audio device. Also during that - if (as often is) device able to process only single input stream - direct streaming to the device seethes it, and as a side effect makes impossible other sounds to pop-up during streaming.

So it can be useful simple feature for musicians and audiophiles. This feature is sort of a poor mans version of Jack.

[Anton-Latukha]

Also as we see - it allows for people to bypass PulseAudio - if PulseAudio has issues on their system.

Also ALSA has a quite powerful DSL inside, can have it's own processing setup, mixer, input virtual devices that Jack or LMMS are connected to.