[pulseaudio-discuss] Card and sink/source specific config

[Alexander E. Patrakov]

2013/4/10 David Henningsson <david.henningsson at canonical.com>:
> I especially like that we can match udev data right in the configuration
> file; rather than having to add specific udev rules.
>
> I'd more like to discuss the actual format of these files.
>
> Perhaps it would be easier to understand if all matching properties begun
> with "match-", e g:
>
> match-udev = ID_PATH="pci-0000:03:07.0"
>
> or
>
> match-name = alsa_card.pci-0000_03_07.0
>
> or
>
> match-property = device.bus_path="pci-0000:03:07.0"
>
> to match one of my sound cards. Matching rules are "AND", i e, if no
> matching specified, it matches any card.
>
> I'd also prefer
>
> match-card = c
>
> on the port, rather than "ports = p1 p2" on the card. So my example would
> look something like:
>
> [alsa_card JuliCard]
> match-property = alsa.card_name="ESI Juli@"
>
> [alsa_sink JuliSink]
> match-card = JuliCard
> modargs = "tsched=0"
>
>
> ...but the complexity can easily grow out of hand. What if we want OR
> conditions between matches, wildcards, and what not. Maybe we should do +=
> instead of = for the modargs?

I think that the fear about complexity is unfounded. This looks almost
exactly like the scheme used by Xorg to set properties on input
devices. To get an exact equivalent, just always use the += semantics
that appends the option or overrides it if that option is set earlier
in the configuration file for the same device. Maybe it makes sense to
ask on xorg-devel what they like about their InputClass solution, what
they don't like, and how did they arrive at the current syntax.

Here is an example of what they do by default:

Section "InputClass"
        Identifier "Disable clickpad buttons on Apple touchpads"
        MatchProduct "Apple|bcm5974"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "0 0 0 0 0 0 0 0"
EndSection

--
Alexander E. Patrakov