[alsa-devel] TLV support for PCM (in driver)

Takashi Iwai tiwai at suse.de
Wed Jan 16 16:38:52 CET 2008


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


More information about the Alsa-devel mailing list