Re: Adding a "capture" device naming scheme

[Takashi Iwai <tiwai@suse.de>]

At Wed, 12 Jan 2011 11:12:42 +0000,
Colin Guthrie wrote:
> 
> '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).

This should work, AFAIK.  The iec958 definition of each card is
usually written for both directions.

> 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)

In a classical case, there is one input stream taking either mux or
mix of several input sources.  The active input source can be switched
via the mixer interface dynamically.

Meanwhile, there are devices that have multiple input streams assigned
to different input sources.  "linein" or "micin" suggested in the
above are in this case.  Each device is dedicated to a single source.
For these, apps need to reopen to a different stream if one wants a
different source.

> 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.

I think PA can use hw indeed.  At least, until we find out a better
way suiting with PA implementation.


thanks,

Takashi