Re: [PATCH] ASoC: core: allow control index different from 0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Oct 5 2016 17:41, Arnaud Pouliquen wrote:
> Thanks for the explanation. Here is my use case:
> I have a card with 3 output devices:
>  hw:0,0 HDMI
> 	associated controls:
> 		numid=1,iface=PCM,name='ELD'
> 		numid=2,iface=PCM,name='IEC958 Playback Default'
> 		numid=3,iface=PCM,name='Freq.Adjustment'
>  hw:0,1 DAC
> 	associated controls:
> 		numid=4,iface=PCM,name=' Freq Adjustment'
>  hw:0,2 SPDIF
> 	associated controls:
> 		numid=5,iface=PCM,name='IEC958 Playback Default'
> 		numid=6,iface=PCM,name='Freq Adjustment'
> 
> My concern is to differentiate the controls associated to the outputs.
> Seems that it could be done using device field, but iecset is based on
> index (or i missed something?).
> Adding an option in iecset to address control by device could solve the
> issue... but it is to good way to handle the use case?
> 
> Complementary solution would be that control device field corresponds to
> PCM device, to allow to address PCM device with args (for instance AESx
> params for iec)
> 
> This is linked to the management of DAI PCM controls that has already
> been discussed in thread associated to this patch:
> http://www.spinics.net/lists/alsa-devel/msg47611.html.
> I can rework my patch (suppress iec generic control, to simplify it)
> but this only treat DAI controls not BE and "dai less" codecs.

Hm. In configuration space (namespace) of alsa-lib, the 'hw:0,1' PCM
node is a short representation of 'pcm.hw:0,1,0'; each member expresses:
 - pcm: interface
 - hw:  plugin name
 - 0:   card number
 - 1:   device number
 - 0:   subdevice number

Next, when identifying a control element, 'struct snd_ctl_elem_id' is
used in ALSA control core. Layout of the structure is in <sound/asound.h>:

struct snd_ctl_elem_id {
  unsigned int numid;
  snd_ctl_elem_iface_t iface;
  unsigned int device;
  unsigned int subdevice;
  unsigned char name[44];
  unsigned int index;
};

Under the above design, when using a proper combination of
iface/card/device/subdevice, we can represent the relationship between a
control element and a PCM node.

But in a case of control elements for IEC 60958 type, we need to read
this patch, commit ea9b43addc4d ("ALSA: hda - Fix broken workaround for
HDMI/SPDIF conflicts").
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b43add

In this commit for former Intel HDA driver, two issues were addressed:
 - multiple codecs gives functionalities of digital interface such as HDMI.
 - bug of mixer interface in alsa-lib

Due to the issues, 'index' field is used, instead of the design I described.

Although, the requirement for HDA codecs (verb parser) and your
requirement is different. I think it better for you to follow the above
design, then fix the bug of mixer interface in alsa-lib. At least, via
the other ctl-related APIs such as ctl/hctl, the control element can be
selected and processed in user land.

> This is linked to the management of DAI PCM controls that has already
> been discussed in thread associated to this patch:
> http://www.spinics.net/lists/alsa-devel/msg47611.html.
> I can rework my patch (suppress iec generic control, to simplify it)
> but this only treat DAI controls not BE and "dai less" codecs.

I can't follow all of messages in the related threads, but:

 [PATCH v3 1/4] ALSA: pcm: add IEC958 channel status control
helper
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105152.html

Takashi Iwai wrote:
> Hmm, this doesn't always work.  It will create the substream_count
> ctls starting from the pcm dev# as index.  What if there are 2 PCM
> devices where both contain 4 substreams?

struct snd_ctl_elem_id.subdevice can represent the index of PCM
substream because current PCM core expresses the substreams as the
subdevices.
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/pcm.c?h=sound-4.9-rc1#n144

 [PATCH v3 1/4] ALSA: pcm: add IEC958 channel status control
helper
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105158.html

Takashi Iwai wrote:
> This pretty much depends on the hardware design.  If each substream is
> really individual, you'd need to give the control for each substream.

I'll assist his advice for your issue.

In next time, please put URIs to your comment so that the other
developers can follow related issues.


Regards

Takshi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux