| Commit message (Collapse) | Author | Age | Files | Lines | 
| |  | 
 | 
| |\  
| | 
| |  | 
Don't connect to pulseaudio with PA_CONTEXT_NOFAIL
 | 
| |/  
|   
|   
|   
|   
|   
|   
|   
|   
|   
|   
|   
|   
|   
|    | 
NOFAIL means we don't fail if the daemon is not available when
pa_context_connect() is called and instead enter PA_CONTEXT_CONNECTING
state and wait for the daemon to appear.
So currently if pulseaudio isn't running or available, ponymix will just
block and wait. Since a lot of people use ponymix bound to their volume
keys, this could potentially mean spawning 100s of processes before
actually catching on that things aren't working.
PA_CONTEXT_NOFLAGS was introduced in 0.9.19. Its really just 0.
Signed-off-by: Simon Gomizelj <simongmzlj@gmail.com>
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Allow for invocations such as "ponymix get-v" or "ponymix -d SB set-d".
Bail when the command is ambiguous and print the possible matches.
This necessarily means changing the return type of string_to_command to
return the whole pair<> out of the action map to allow for useful errors
when we do arg checking (as we don't necessarily have the full command
name from the user).
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
|  | 
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.
 | 
| | |  | 
 | 
| | |  | 
 |