Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Takashi Iwai <tiwai@suse.de>]

On Tue, 20 Oct 2015 17:18:16 +0200,
Mauro Carvalho Chehab wrote:
> > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > and mixers).
> 
> Yeah, the graph is simplified, as for now we only needed to represent
> the parts of the graph that are associated with the ALSA interfaces.

So this doesn't expose the graphs inside USB-audio chip but rather
only the mixer elements parsed by ALSA driver, right?  That's what I
understood from Shuah's patchset, so far.

> > It may be good to have a cmd line option to stop at certain
> > nodes on the graph to avoid over populated/complex graphs ?
> 
> Yes, it makes sense to have some ways to simplify the graph plot.
> Yet, I'm not sure yet what would be the best ways to simplify
> the graph when plotted, as this is not a simple task.
> 
> For example, on the au0828/snd-usb-audio graph, the dvb-demux entity 
> actually has a lot more than 5 source PADs. The demux basically gets
> a MPEG-TS stream and splits audio, video and data channels on different
> I/O outputs. Most drivers (including au0828) have 256 outputs.
> Each node connected to two or more I/O entities. On an USB driver
> like this one, those outputs are seen via two device nodes, but
> TV sets and Set Top Boxes provide ways to wire the output of the
> demux to the aSoC and to the DRM driver, in order to be able to
> output sound and video directly. On some hardware, it is even possible
> to reboot the CPU keeping those wires while the CPU reboots. So, the
> user may not even notice if the CPU reboots due to some trouble.
> 
> So, we need all outputs of the demux to be controlled by the Media
> Controller, for it to allow dynamically route audio and video to
> the right entities at the ALSA and DRM parts of the graph.
> 
> The au0828 graphs that Shuah and I have were generated with a Kernel
> hack patch that reduces the number of outputs to just 5, just to make
> the graph visually readable. Of course, such patch should not be sent
> upstream, and we need to find a solution on userspace to simplify
> the graph on plots.
> 
> There are some ways that we could do that:
> 
> 1) we could group entities/interfaces per subsystem. So, if all the user
> wants is to see ALSA-related nodes, it will filter out the other nodes
> (eventually, keeping the nodes that are directly connected to ALSA
> but belongs to the other subsystems);

This actually made me wonder how all things are managed.  Are all
mapped into the same topology, or they are individual trees (e.g. per
device object)?


thanks,

Takashi