'Twas brillig, and Jaroslav Kysela at 12/01/11 09:17 did gyre and gimble:
On Wed, 12 Jan 2011, Colin Guthrie wrote:
'Twas brillig, and Takashi Iwai at 12/01/11 06:53 did gyre and gimble:
I read Colin meant front:CARD=x is incorrect while hw:CARD is a lowlevel access that one doesn't always want.
For capture. Yes that's what I was meaning.
I'm fine with creating a new name, but wondering which name is best. Basically what you want here is the default use-case but without dsnoop like the current "default". (If dsnoop were acceptable, "default" should have been used in most places.) "capture" may be also too ambiguous for defining that, I'm afraid.
Yeah, "default" wont work here due to it being redirected to PulseAudio (as opposed to dsnoop) in this use case, so we need to avoid that name :s
IMO "capture" is quite clear (or at least as clear as "front" is for playback!), but here are a few other suggestions:
"record" "input" "read"
Personally, "input" and "capture" are my two favourites.
The question is, if we should identify more the source of the captured data. The default device does the basic job.
analogin iec958in
Eventually:
linein micin iec958in
Well in the case of digital in I think "iec958" (or spdif) is used directly (but could be wrong).
In 98% of cases, using front for recording works fine, but it is technically wrong as Raymond pointed out several times on other threads. Is it "technically wrong" to use iec958 for input? If so the then same change we'll need to add for analog recoding would also cope quite fine with digital recording, so adding a iec958in wouldn't really be a problem in my book.
As for line vs mic etc, is this not usually handled by different [sub]devices and/or switch elements? Would it really be possible to wrap up such permutations in a config name without a lot of extra work? (please forgive my ignorance here)
If we can't decide, we'll just have to tweak PA to use hw: directly for input but it would seem like a cleaner design to have a proper name for it.
Col