[alsa-devel] Adding a "capture" device naming scheme
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
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 ,
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
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 ?
'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
'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
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.
'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
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
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
'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
participants (4)
-
Colin Guthrie -
Jaroslav Kysela -
Raymond Yau -
Takashi Iwai