> I understand that, but it was pointed out that alsa could not do that "out of
> the box", and pulse audio could. And you have said that you wanted to use
> software that does stuff that others cannot.

Maybe I made a mistake in reading the order of the messages. Until the
last Mr. Clemens's message, I wasn't aware ALSA can't do this - I was
sure that it can and that I just need to learn how.

This caused my poor wording, where I said that I wanted to use software
that does stuff that other software can't - in reality, if Alsa wouldn't
be able to even route to two outputs at once (a solution suggested on
IRC), I'd probably just shrug and just stick with environmentals, the
way it works now.

> No. That is not your problem. That is your solution. You problem is that you
> want to be able to change outputs on the fly and seamlessly. Of course it
> "is possible" since pulseaudio uses alsa and manages to do this. But you
> would rather write extra software on your own to solve the problem
> than use a solution that is already there. That was my observation. Of course
> doing that is certainly your right, but it seems contradictory with what you
> claim you use software for.

That's a pretty correct observation, I myself wasn't actually aware that
I'm pushing for one specific type of solution until you just pointed it,
and I *was* initially trying to avoid specifying my issue as an XY
problem :-\

> Of course it is not, more power to them. However, it just seems perverse to me
> that when a solution exists, a solution which you state does what you want,
> that you then persist in trying to find a different solution which is not
> straightforward or requires additional work by you.
> Now if you have said that PA has caused you problems in the past and gets in
> the way of your accomplishing other things you do, that might be reason. But
> that does not appear to be the case. You seem to rule out PA by shear
> prejudice. When one of the main developers of ALSA asks what you have against
> PA, it suggests that you have galloped off into the wilderness rather than
> taking the straightforward route to a solution to your problem.

I see. I am not prejudiced against PA, I swear :-)
I try hard to keep a lean system, for no real reason but as my own
hobby. I understand what every process on my htop list does, where is it
configured, how, when does it boot and when does it go to sleep. If
you'd call this perverse, I'd agree with you :-)

Maybe I misunderstand how the whole audio stack works. I did use
PulseAudio about 5 years ago, as it tags along with any gnome/kde
package groups, but I remember reading somewhere on reddit that PA isn't
really a necessary part of linux audio.
It really didn't take me that long to learn how alsa.conf works and how
to configure the audio in my system the way I'd want it to work.

Anyway, please let me try to restate my problem and the context of it:
through these past 5 years, Alsa itself did 100% of what I wanted.  I've
recently added 5.1 processor to my man cave, and hooked it up to my main
machine (a laptop) with HDMI.
Its real easy to run mplayer with prepending an environmental, to make
the sound go to the HDMI - but not all processes I run are so
short-lived. My browser tends to have uptime as long as my machine
(15-20 days), and I thought it'd be great if I could just flick a switch
(ideally through a console, so I can hook that up with xmonad.hs to a
button) and have default sound device switch. I have basic understanding
of alsa's terminology and way of doing things (through plugin chains) so
I assumed this would be a way to do this.

I have a real hard time reasoning to myself that I should switch to a
secondary mixing system that ignores all of Alsa's features, just for
this last 1% of dynamic switching.
I'd really rather just shut down and restart my browser in this case.

Maybe that *is* perverse, I don't know...

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Alsa-user mailing list

Reply via email to