[alsa-devel] TLV support for PCM (in driver)
Hi,
I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack:
a) get channel info / name / position (e.g. Front Left Speaker) - not sure how to handle multichannel cards - I'm sure that this is something to be user configurable b) get possible channels c) get possible formats d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.) e) eventually more information for device name hinting for userspace (current problems for HDA, AC97, USB devices are that we have only one .conf file per driver covering all hardware - we need to detect real device capabilities and show only devices which can be really used)
Opinions?
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Wed, 16 Jan 2008 15:23:37 +0100 (CET), Jaroslav Kysela wrote:
Hi,
I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack:
a) get channel info / name / position (e.g. Front Left Speaker)
- not sure how to handle multichannel cards
This won't work with the static TLV because the channel mapping is a dynamic information. It varies depending on the hw_params setting. A typical difference is the mappings between 4 and 6 channels (FL/FR/RL/RR and FL/FR/C/LFE/RL/RR).
- I'm sure that this is something to be user configurable
Everything is user-configurable :)
But the channel mapping is basically bound to the driver implementation, so rather there is no real user-configuration, AFAIK.
I've already hacked to extend channel_info to include this information. If you're interested, I'll post patches.
b) get possible channels c) get possible formats
These *could* be dynamic, too. That's why we have a complex hw_params procedure. But, they are static for most cases, so it would likely work.
d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.)
This sounds good. Any practical use in mind?
e) eventually more information for device name hinting for userspace (current problems for HDA, AC97, USB devices are that we have only one .conf file per driver covering all hardware - we need to detect real device capabilities and show only devices which can be really used)
This would be helpful, too.
Takashi
On Wed, 16 Jan 2008, Takashi Iwai wrote:
At Wed, 16 Jan 2008 15:23:37 +0100 (CET), Jaroslav Kysela wrote:
Hi,
I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack:
a) get channel info / name / position (e.g. Front Left Speaker)
- not sure how to handle multichannel cards
This won't work with the static TLV because the channel mapping is a dynamic information. It varies depending on the hw_params setting. A typical difference is the mappings between 4 and 6 channels (FL/FR/RL/RR and FL/FR/C/LFE/RL/RR).
- I'm sure that this is something to be user configurable
Everything is user-configurable :)
But the channel mapping is basically bound to the driver implementation, so rather there is no real user-configuration, AFAIK.
I've already hacked to extend channel_info to include this information. If you're interested, I'll post patches.
b) get possible channels c) get possible formats
These *could* be dynamic, too. That's why we have a complex hw_params procedure. But, they are static for most cases, so it would likely work.
Ok, I didn't explain the term "static" as well. I think that the best way might be to group parameters like:
parameters #1 { channels { 2 { FL, FR } 4 { FL, FR, RL, RR } 6 { FL, FR, C, LFE, RL, RR } } formats { S16_LE, S32_LE } } parameters #2 { .... }
Just idea. We can get this change as base to change from refine method to provide a list of possible values method and reduce the kernel and alsa-lib code.
d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.)
This sounds good. Any practical use in mind?
I think that Lennart Poettering requirested this and I think that it might make sense for various TV Linux boxes ;-)
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Wed, 16 Jan 2008 16:19:35 +0100 (CET), Jaroslav Kysela wrote:
On Wed, 16 Jan 2008, Takashi Iwai wrote:
At Wed, 16 Jan 2008 15:23:37 +0100 (CET), Jaroslav Kysela wrote:
Hi,
I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack:
a) get channel info / name / position (e.g. Front Left Speaker)
- not sure how to handle multichannel cards
This won't work with the static TLV because the channel mapping is a dynamic information. It varies depending on the hw_params setting. A typical difference is the mappings between 4 and 6 channels (FL/FR/RL/RR and FL/FR/C/LFE/RL/RR).
- I'm sure that this is something to be user configurable
Everything is user-configurable :)
But the channel mapping is basically bound to the driver implementation, so rather there is no real user-configuration, AFAIK.
I've already hacked to extend channel_info to include this information. If you're interested, I'll post patches.
b) get possible channels c) get possible formats
These *could* be dynamic, too. That's why we have a complex hw_params procedure. But, they are static for most cases, so it would likely work.
Ok, I didn't explain the term "static" as well. I think that the best way might be to group parameters like:
parameters #1 { channels { 2 { FL, FR } 4 { FL, FR, RL, RR } 6 { FL, FR, C, LFE, RL, RR } } formats { S16_LE, S32_LE } } parameters #2 { .... }
Just idea. We can get this change as base to change from refine method to provide a list of possible values method and reduce the kernel and alsa-lib code.
This looks promising. The similar mechanism is already in USB-audio and HD-audio protocols, and it's confirmed to work in most cases, so far.
d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.)
This sounds good. Any practical use in mind?
I think that Lennart Poettering requirested this and I think that it might make sense for various TV Linux boxes ;-)
Of course, PA would need such every detailed h/w information! ;)
Takashi
participants (2)
-
Jaroslav Kysela -
Takashi Iwai