Adding a "capture" device naming scheme

Adding a "capture" device naming scheme

[Colin Guthrie]

Hi,

As has been pointed out a few times, it's incorrect to use "front:" for
capture, but can we have an official name/wrapper (I'm unsure of the
terminology here) for this so we don't use hw: for recording?

I'd be in favour of "capture:" or "input:" as these both seem quite
logical and easy to understand.

It would be used thusly:

  arecord -f S16_LE -c 2 -D capture:CARD=Intel

as opposed to the incorrect:
  arecord -f S16_LE -c 2 -D front:CARD=Intel
or the low level:
  arecord -f S16_LE -c 2 -D hw:CARD=Intel

Keeping it wrapped up allows for e.g. softvol or other things to be
plugged in as appropriate in the config and thus future proofs things a
little.

If someone could point me roughly in the right direction I'll make a
patch. I suspect it'll be easy enough to cook up the relevant config
needed (and I suspect it's just config rather than code that needs
patched, but I could be wrong).

It would be nice to get this into a release (alsa-lib?) soon so that it
can propigate and we can require it.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Adding a "capture" device naming scheme

[Raymond Yau]

2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>

> Hi,
>
> As has been pointed out a few times, it's incorrect to use "front:" for
> capture, but can we have an official name/wrapper (I'm unsure of the
> terminology here) for this so we don't use hw: for recording?
>
> I'd be in favour of "capture:" or "input:" as these both seem quite
> logical and easy to understand.
>
> It would be used thusly:
>
>  arecord -f S16_LE -c 2 -D capture:CARD=Intel
>
> as opposed to the incorrect:
>  arecord -f S16_LE -c 2 -D front:CARD=Intel
> or the low level:
>  arecord -f S16_LE -c 2 -D hw:CARD=Intel
>

why do you think that it is incorrect to use hw:CARD=xxx for analog capture
?

since you need the low level to handle the phase inversion of the stereo mic

if you don't like the "plug" plugin , you will also don't like the "route"
plugin too

alsa-lib still use the sound card's default device if the linux distribution
does not override  pcm.!default by pulse ,

Re: Adding a "capture" device naming scheme

[Takashi Iwai]

At Wed, 12 Jan 2011 09:08:37 +0800,
Raymond Yau wrote:
> 
> 2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>
> 
> > Hi,
> >
> > As has been pointed out a few times, it's incorrect to use "front:" for
> > capture, but can we have an official name/wrapper (I'm unsure of the
> > terminology here) for this so we don't use hw: for recording?
> >
> > I'd be in favour of "capture:" or "input:" as these both seem quite
> > logical and easy to understand.
> >
> > It would be used thusly:
> >
> >  arecord -f S16_LE -c 2 -D capture:CARD=Intel
> >
> > as opposed to the incorrect:
> >  arecord -f S16_LE -c 2 -D front:CARD=Intel
> > or the low level:
> >  arecord -f S16_LE -c 2 -D hw:CARD=Intel
> >
> 
> why do you think that it is incorrect to use hw:CARD=xxx for analog capture
> ?

I read Colin meant front:CARD=x is incorrect while hw:CARD is a lowlevel
access that one doesn't always want.

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.


thanks,

Takashi

Re: Adding a "capture" device naming scheme

[Raymond Yau]

2011/1/12 Takashi Iwai <tiwai@suse.de>

> At Wed, 12 Jan 2011 09:08:37 +0800,
> Raymond Yau wrote:
> >
> > 2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>
> >
> > > Hi,
> > >
> > > As has been pointed out a few times, it's incorrect to use "front:" for
> > > capture, but can we have an official name/wrapper (I'm unsure of the
> > > terminology here) for this so we don't use hw: for recording?
> > >
> > > I'd be in favour of "capture:" or "input:" as these both seem quite
> > > logical and easy to understand.
> > >
> > > It would be used thusly:
> > >
> > >  arecord -f S16_LE -c 2 -D capture:CARD=Intel
> > >
> > > as opposed to the incorrect:
> > >  arecord -f S16_LE -c 2 -D front:CARD=Intel
> > > or the low level:
> > >  arecord -f S16_LE -c 2 -D hw:CARD=Intel
> > >
> >
> > why do you think that it is incorrect to use hw:CARD=xxx for analog
> capture
> > ?
>
> I read Colin meant front:CARD=x is incorrect while hw:CARD is a lowlevel
> access that one doesn't always want.
>
> 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.
>
>
> thanks,
>
> Takashi
>

Does all HDA codec support multistreaming capture since HDA spec seem have a
limitation on the number of capture stream or just ALSA does not support
multistreaming ?

http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm
#multistream

some realtek codec put another analog capture device at hw:0,2

It seem that some VIA codec support "multistreaming" capture since it  has
an indepedent ADC which can only connect to the front panel mic and the
driver create have two subdevices

As device 0 support multi channels but those alternate stream support stereo
only

can the HDA driver assign analog_alt_playback and analog_alt_capture in the
same device ?

Re: Adding a "capture" device naming scheme

[Raymond Yau]

2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>

> Hi,
>
> As has been pointed out a few times, it's incorrect to use "front:" for
> capture, but can we have an official name/wrapper (I'm unsure of the
> terminology here) for this so we don't use hw: for recording?
>
>
My sb live! platinum when using "mono profile" which use  "hw:0" does not
output any sound

it seem that emu10k1 have to use "front:0" for playing mono

Re: Adding a "capture" device naming scheme

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 12/01/11 08:53 did gyre and gimble:
> 2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>
> 
>> Hi,
>>
>> As has been pointed out a few times, it's incorrect to use "front:" for
>> capture, but can we have an official name/wrapper (I'm unsure of the
>> terminology here) for this so we don't use hw: for recording?
>>
>>
> My sb live! platinum when using "mono profile" which use  "hw:0" does not
> output any sound
> 
> it seem that emu10k1 have to use "front:0" for playing mono

What has playback got to do with this?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Adding a "capture" device naming scheme

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 12/01/11 08:38 did gyre and gimble:
> 2011/1/12 Takashi Iwai <tiwai@suse.de>
> 
>> At Wed, 12 Jan 2011 09:08:37 +0800,
>> Raymond Yau wrote:
>>>
>>> 2011/1/12 Colin Guthrie <gmane@colin.guthr.ie>
>>>
>>>> Hi,
>>>>
>>>> As has been pointed out a few times, it's incorrect to use "front:" for
>>>> capture, but can we have an official name/wrapper (I'm unsure of the
>>>> terminology here) for this so we don't use hw: for recording?
>>>>
>>>> I'd be in favour of "capture:" or "input:" as these both seem quite
>>>> logical and easy to understand.
>>>>
>>>> It would be used thusly:
>>>>
>>>>  arecord -f S16_LE -c 2 -D capture:CARD=Intel
>>>>
>>>> as opposed to the incorrect:
>>>>  arecord -f S16_LE -c 2 -D front:CARD=Intel
>>>> or the low level:
>>>>  arecord -f S16_LE -c 2 -D hw:CARD=Intel
>>>>
>>>
>>> why do you think that it is incorrect to use hw:CARD=xxx for analog
>> capture
>>> ?
>>
>> I read Colin meant front:CARD=x is incorrect while hw:CARD is a lowlevel
>> access that one doesn't always want.
>>
>> 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.
>>
>>
>> thanks,
>>
>> Takashi
>>
> 
> Does all HDA codec support multistreaming capture since HDA spec seem have a
> limitation on the number of capture stream or just ALSA does not support
> multistreaming ?
> 
> http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm
> #multistream
> 
> some realtek codec put another analog capture device at hw:0,2
> 
> It seem that some VIA codec support "multistreaming" capture since it  has
> an indepedent ADC which can only connect to the front panel mic and the
> driver create have two subdevices
> 
> As device 0 support multi channels but those alternate stream support stereo
> only
> 
> can the HDA driver assign analog_alt_playback and analog_alt_capture in the
> same device ?

All of this is very interesting Raymond, but please don't hijack this
thread to discuss something different.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Adding a "capture" device naming scheme

[Colin Guthrie]

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

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Adding a "capture" device naming scheme

[Jaroslav Kysela]

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

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Adding a "capture" device naming scheme

[Colin Guthrie]

'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


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Adding a "capture" device naming scheme

[Takashi Iwai]

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