| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Add a Notifier virtual base class and a CommandLineNotifier
implementation which handles output of volume and balance levels after a
change.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Not sure this is the best way, but it's relatively clean, and it works.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Avoid invoking the copy constructors and storing new objects which can't
be returned (as they're local variables).
|
| |
|
| |
|
|
|
|
| |
Updated but doesn't include card/profile completion
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* pwnymix/master: (25 commits)
show description in list-short
properly clamp values in Set{Balance,Volume}
resolve the card choice as late as possible
allow card lookup by index
Cleanup manpage, reintroduce application commands section
add manpage
reorg usage output
remove defunct enum
implement -short variations of list verbs
A dash of color...
fix abort on set-profile after removing profile
whitespace police
remove string_to_device; PulseClient can do this now
always defined behaviors for devices
Derive the card from the targetted device
ponymix: validate arg count before invoking function
rename class Pulse to PulseClient
makefile: CFLAGS -> CXXFLAGS
eschew _unused_ attribute
alias sane types to --device flags
...
Conflicts:
Makefile
ponymix.1
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Avoid some needless churn of back and forth between a card name and
Card*. We rarely actually need the card unless we're performing an
operation on it, so delay it as long as possible. Add a convenience
function to resolve the active card or die.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
99d86934399e9 implies that I lied. move and kill have special behavior
since they only ever really operate on sink-inputs and source-outputs.
Reflect this in Kill on the frontend, since it previously required the
exact device type.
|
| |
| |
| |
| | |
Yay, the makefile is no longer a lie!
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
ponymix set-profile off
ponymix set-profile output:stereo-da+input:stereo-analog
<kaboom>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unless explicitly specified, target a card based on the selected device.
Note that not all devices will be tied to a card.
falconindy » put differently, if i have multiple cards, what determines which
card is used by pulse for a given app?
tanuk » In theory, the logic can be anything (it depends on what
policy-implementing modules are loaded). By default, routing is mostly
handled by module-stream-restore, which chooses the sink based on the
user's previous routing choices.
tanuk » If the user hasn't done any routing choices, the fallback logic is to
select the current "default sink".
tanuk » I don't recommend trying to guess the routing policy.
falconindy » i guess my understanding of pulse internals is lacking
falconindy » but that's rather enlightening
falconindy » is there any way to figure out the connection between a sink and a card?
tanuk » Yes... (One moment, I'll look up things.)
falconindy » ah. uint32_t card
falconindy » appears to be in pa_sink_info
falconindy » so that ties the sink to the index of a card?
tanuk » Yep.
falconindy » awesome, that's good enough for what i need to do
tanuk » Not all sinks are part of a card, though, but those that are will have
the card index set.
falconindy » also good to know
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A few changes make this fun and easy:
- Merge the function array into the string to action lookup and return a
Command instead of simply an enum. A Command is the function and the
min/max arg count.
- Implement an InRange method for the Range class.
- Add a Dispatch function to convert the string to Command and validate
the arguments.
This leaves us in a position where the argc parameter to each method is
never used, but maybe some day a command will be added that takes a
range of args rather than a fixed number.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
A sources-output can only be moved to a new source, and a sink-input can
only be moved to a new sink. So, derive the target type based on this.
Also, reroute sink -> sink-input and source -> source-output to save
some keystrokes.
|
| | |
|
| | |
|
| | |
|